Video is missing captions

What is this issue?

A <video> element plays prerecorded content with spoken dialogue or other informative audio, but has no <track> child using kind="captions". Captions are timed, synchronized text that appears alongside the video, including both spoken dialogue and important non-speech sound cues (“door slams,” “audience laughs”) that a hearing viewer picks up automatically but a deaf or hard-of-hearing viewer has no access to without them.

This is distinct from subtitles, which assume the viewer can already hear the audio and only need the dialogue in another language or in text form; subtitles routinely omit sound-effect cues that captions are specifically written to include.

Why does this matter?

Deaf and hard-of-hearing viewers can see everything a video shows but get none of what it says without captions; the visual channel alone is often not enough to follow a training video’s instructions, an interview’s actual answers, or a product demo’s spoken explanation of what’s happening on screen. This affects a substantial number of people: roughly one in six people worldwide has some degree of hearing loss, a far larger group than most teams account for when they treat captions as an edge case.

Captions also help far beyond deaf and hard-of-hearing viewers in practice: anyone watching in a sound-sensitive environment, a noisy commute, a shared office, a public space where audio would be disruptive, relies on the same caption track to follow along without sound. In many real-world viewing contexts, captioned viewers without hearing loss substantially outnumber viewers actually listening to the audio.

Who is affected?

• Deaf and hard-of-hearing viewers: can see the video but miss spoken dialogue, narration, and sound-effect cues entirely without captions. There’s no partial signal available from picture alone for content that depends on what’s said, not just what’s shown.
• Cognitive disabilities: viewers with certain attention or auditory-processing differences often follow spoken content more reliably in text form, benefiting from captions independently of hearing ability.

What users experience

Naomi is hard of hearing and relies on captions to follow spoken video content. She opens a company’s onboarding video, which walks new employees through setting up their accounts step by step entirely through narration over screen-recording footage. There’s no <track kind="captions"> on the video, so she can see the screen being clicked through but has no way to know which specific fields the narrator says to fill in or what values to enter. She has to guess from the visuals alone or ask a colleague to walk her through the same steps a fully captioned video would have let her complete independently.

How do I fix it?

Add a <track> element inside the <video> tag, pointing to a WebVTT caption file, with kind="captions" specifically. This works because kind="captions" tells browsers and assistive technology this track includes both dialogue and sound-effect information for viewers who can’t hear any of the audio; kind="subtitles" signals a different, narrower purpose and shouldn’t be used as a substitute.

If you’re using a third-party video platform like YouTube or Vimeo instead of a native <video> element, enable and review captions through the platform’s own embed settings rather than trying to add a <track> element, since the embedded player handles its own caption delivery.

Code Examples

<video src="/onboarding.mp4" controls></video>

<video src="/onboarding.mp4" controls>
  <track
    kind="captions"
    src="/captions/onboarding.en.vtt"
    srclang="en"
    label="English"
    default
  >
</video>

The <track> element gives browsers a caption file to display and lets viewers toggle it on or off through the video’s own controls, while the default attribute makes captions appear automatically the first time the video plays, rather than requiring every viewer to discover and enable them manually.

Common Mistakes

Mistake: “kind="subtitles" and kind="captions" are basically interchangeable.” They signal different purposes to browsers and assistive technology. Subtitles assume the viewer can hear the audio and only need dialogue as text; captions are written for viewers who can’t hear anything and include sound-effect descriptions subtitles typically leave out. Use kind="captions" for this requirement specifically.

Mistake: “The video’s title and surrounding page text already explain what it’s about, so captions are optional.” Surrounding text can describe a video’s general topic, but it can’t substitute for the specific words spoken minute by minute: instructions, exact figures, direct quotes. A deaf viewer following an onboarding video needs the actual steps said aloud, not a summary of the video’s purpose.

Mistake: “Auto-generated captions from the video platform are close enough without review.” Automatic speech recognition frequently mis-transcribes names, technical terms, and accented or fast speech, sometimes changing the apparent meaning of what was said. Review and correct auto-generated captions before publishing, especially for instructional or factual content.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s video-caption rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects every <video> element for a child <track> with kind="captions" or kind="subtitles".

False negative: axe-core confirms a caption track element is present; it cannot verify the referenced .vtt file actually exists, loads correctly, or contains accurate, complete captions. A <track> pointing at a broken or empty caption file still passes the automated check. False positive: a <video> used purely for silent background footage with no audio track at all can be flagged even though no captions are needed, since axe-core checks for the track element’s presence rather than whether the video actually has informative audio. Manual step: confirm the caption file loads, displays correctly, and accurately reflects everything spoken in the video, including non-speech sound cues.

Manual Testing

1. Open the page in a browser and locate every <video> element with spoken dialogue or narration.
2. Turn on captions using the video player’s controls.
3. Play the video and confirm the captions display, are synchronized to what’s said, and include non-speech sound information where relevant, such as “[phone rings].”
4. If no caption option exists, or the displayed captions are missing, badly out of sync, or clearly inaccurate, the check fails.

Related WCAG Success Criteria

1.2.2 Captions (Prerecorded): Captions must be provided for all prerecorded audio content in synchronized media. A video with spoken content and no caption track fails this criterion directly.

Related Issues

Audio element has no caption track covers the sibling requirement for audio-only content, where a standalone transcript rather than timed captions is the expected fix.

Page auto-plays audio or video with sound shares the same media element and affected-user overlap; both rules concern how audio and video content is delivered responsibly.

Image is missing alt text shares the same underlying WCAG principle from a different angle: content in one sensory format needs an equivalent in another for users who can’t perceive the original.

References

• W3C Understanding 1.2.2: Captions (Prerecorded)
• MDN: track element
• WebAIM: Captions, Transcripts, and Audio Descriptions