WCAG 1.2.2: Captions (Prerecorded)
A deaf viewer cannot hear your narrator, a commuter with the sound off cannot follow your product demo, and a search engine cannot index spoken words. This criterion asks that every prerecorded video with audio carries synchronized captions that convey the dialogue, who is speaking, and the meaningful sounds — so the whole video works with the audio muted.
The success criterion, in full
Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
“Synchronized media” means audio or video synchronized with another format (usually a soundtrack synchronized with moving pictures). The rule is short but exact: all prerecorded audio in that media needs captions, and the only way out is the narrow media-alternative exception — when the video simply re-presents text that is already fully available on the page and is clearly labeled that way.
Who this helps
Captions were designed for deaf and hard-of-hearing viewers, but a text layer over spoken audio turns out to help far more people than that — anyone who cannot, or would rather not, rely on sound:
Deaf and hard-of-hearing viewers
The primary audience. Without captions, all spoken dialogue, narration, and meaningful sound is simply inaccessible — the video is silent to them.
People in sound-off environments
Viewers in open offices, libraries, quiet trains, or late-night rooms — and the large share of social-media users who watch video muted by default — read the captions instead of playing audio.
Non-native speakers
Seeing the words written out alongside the audio makes fast or accented speech far easier to follow, and helps learners connect spoken and written language.
People with auditory processing or attention differences
Reading along with the audio reinforces comprehension and helps maintain focus for viewers with auditory processing disorders, ADHD, or similar conditions.
Viewers with lower literacy or in noisy audio
Captions reinforce unfamiliar vocabulary and rescue moments where the audio mix is muddy, an accent is unfamiliar, or a term is easily misheard.
Search engines and everyone
Caption text is indexed by search engines and makes video content searchable and quotable — good captions are also good SEO, benefiting every visitor.
What the requirement covers
1.2.2 applies to prerecorded synchronized media — any stored video whose soundtrack is synchronized with the moving picture: tutorials, webinars-on-demand, product demos, testimonials, marketing clips, and training videos. If it has meaningful audio and it was recorded before it was published, it needs captions. The important thing to understand is that captions are not the same as subtitles — they must carry all of the audio information, not just the words:
- All spoken dialogue and narration. Every word said by every speaker, transcribed accurately — not paraphrased or summarized.
- Speaker identification. When it is not obvious who is talking, label the speaker: [Narrator]:, [Dr. Lee]:, or a name/colour convention. This keeps multi-person dialogue followable.
- Meaningful non-speech audio. Sound effects and music that carry information or mood, written as descriptions: [applause], [door slams], [phone rings], [tense music builds]. Incidental sounds with no meaning can be left out.
- Synchronized timing. Captions must appear as the corresponding audio plays, roughly in step with the speech, so text and picture stay together.
Open vs. closed captions
Closed captions live in a separate track (such as a WebVTT file loaded through a <track> element) that viewers can toggle on or off, restyle, and switch between languages. Open captions are burned permanently into the video image and are always on. Either can satisfy 1.2.2, but closed captions are usually the better choice: they are searchable, resizable, optional, and can carry multiple languages, whereas open captions cannot be turned off and degrade when the video is recompressed.
Why auto-generated captions usually fail
Automatic speech recognition is a useful first draft, not a finished caption track. It misspells names and jargon, guesses wrong on homophones, drops punctuation, rarely marks who is speaking, and almost never describes non-speech sounds. Because WCAG requires captions that accurately and completely represent the audio, uncorrected auto-captions generally do not conform. Always have a human review the transcript, fix errors, add speaker labels and non-speech descriptions, and correct the timing before publishing.
The one exception
Captions are not required when the media is a media alternative for text and is clearly labeled as such — that is, when the video only re-presents information already available as readable text on the same page. This exception is narrow and rarely applies. Note that 1.2.2 is only the caption requirement; the same video may also need audio description or a full text alternative under the other 1.2.x Time-based Media criteria, and live video is covered separately by 1.2.4.
Pass and fail examples
✓ Passes 1.2.2
- A tutorial video with a synchronized caption track that transcribes all dialogue and labels the speaker.
- Captions that describe meaningful non-speech audio, e.g. “[upbeat music starts]” and “[applause]”.
- Open captions burned into a promo clip so the words are always visible.
- Human-reviewed captions corrected from an auto-generated draft, with names and terms fixed.
- A short video with no captions that only re-presents text printed in full on the same page, clearly labeled as an alternative.
✗ Fails 1.2.2
- A product demo with a soundtrack and no caption track at all.
- Raw YouTube auto-captions full of misheard words, no speaker labels, and no sound descriptions.
- Subtitles that translate the dialogue but omit music and sound effects that carry meaning.
- Captions so far out of sync that they lag several seconds behind the speech.
- Captions that summarize or skip dialogue instead of transcribing what is actually said.
Code examples
A video with no captions vs. one with a caption track
The fix is usually a single <track> element pointing at a caption file. Use kind="captions" (captions for the deaf), not kind="subtitles".
<!-- ✗ Prerecorded video with audio and no captions -->
<video src="workshop.mp4" controls></video>
<!-- ✓ Same video with a synchronized caption track -->
<video src="workshop.mp4" controls>
<track
kind="captions"
srclang="en"
label="English"
src="workshop.en.vtt"
default>
</video>What the WebVTT caption file looks like
A WebVTT file pairs each cue with a start and end time. Notice the speaker label and the bracketed non-speech sounds — these are what make it a caption track rather than a subtitle track.
WEBVTT
00:00:00.000 --> 00:00:03.000
Welcome to our accessibility workshop.
00:00:03.000 --> 00:00:06.000
[Dr. Lee]: Today we'll learn about video captions.
00:00:06.000 --> 00:00:09.000
[upbeat music starts]
Captions help deaf and hard-of-hearing viewers.
00:00:12.000 --> 00:00:15.000
[applause] Let's see how to implement them.Multiple caption languages
You can offer several caption tracks; mark one default and let the player expose the rest through its captions menu.
<video src="workshop.mp4" controls>
<track kind="captions" srclang="en" label="English"
src="workshop.en.vtt" default>
<track kind="captions" srclang="es" label="Español"
src="workshop.es.vtt">
<track kind="captions" srclang="fr" label="Français"
src="workshop.fr.vtt">
</video>Interactive demo
Play the simulated video and toggle its captions to feel the difference between having and lacking them, then practice writing your own caption track and watch the live feedback on timing, speaker labels, and non-speech sounds.
Turn captions off to experience the video the way a deaf or hard-of-hearing user would without them.
Accessibility Workshop (simulated video)
Audio plays here
Welcome to our accessibility workshop.
Full caption track
0:00 - 0:03: Welcome to our accessibility workshop.
0:03 - 0:06: [Dr. Lee]: Today we'll learn about video captions.
0:06 - 0:09: [Upbeat music starts] Captions help deaf and hard of hearing users.
0:09 - 0:12: They also help people in noisy or sound-off environments.
0:12 - 0:15: [Applause] Let's see how to implement them properly.
Practice writing captions
Write captions for a short clip. Include timestamps, speaker identification, and non-speech audio — the feedback updates as you type.
Common failures
- Publishing a prerecorded video with audio and no caption track at all — the most common failure.
- Leaving raw auto-generated captions uncorrected, so names, jargon, and homophones are wrong.
- Providing subtitles (dialogue only) and treating them as captions, omitting music and sound effects.
- Omitting speaker identification, so viewers cannot tell who is talking in a multi-person video.
- Dropping meaningful non-speech audio — [applause], [alarm], [ominous music] — that carries information or mood.
- Captions that drift out of sync and lag behind the spoken audio.
- Summarizing or paraphrasing dialogue instead of transcribing what is actually said.
- Relying on a text transcript elsewhere as a substitute — a transcript is not synchronized captions.
- Using the media-alternative exception for a video whose content is not already fully available as text on the page.
How to test for 1.2.2
- 1
Inventory every prerecorded video
Find all stored videos with meaningful audio — <video> elements, embedded YouTube/Vimeo players, background clips with narration. Exclude live streams (those fall under 1.2.4) and silent or purely decorative video.
- 2
Confirm a caption track exists and is on
For each video, check that captions can be enabled (a CC control, a <track kind="captions"> element, or burned-in open captions) and that the track actually loads and displays.
- 3
Watch with the sound completely off
Mute the audio and watch the whole video using captions only. Ask whether you understood everything a hearing viewer would — this is the core test of 1.2.2.
- 4
Check completeness, not just presence
Verify captions include all dialogue, identify speakers where needed, and describe meaningful non-speech audio like music and sound effects. A track that exists but omits these still fails.
- 5
Check accuracy and synchronization
Read along with the audio: names, technical terms, and punctuation should be correct, and captions should appear roughly in step with the speech rather than lagging behind.
- 6
Verify the caption controls are accessible
Make sure the caption toggle can be reached and operated by keyboard and is announced by a screen reader, so users can turn captions on without a mouse.
For a structured audit, work through the full WCAG 2.2 checklist.
Related Success Criteria
Provide alternatives for prerecorded audio-only and video-only content.
Audio description or full text alternative is provided for prerecorded video content.
Captions are provided for all live audio content in synchronized media.
Audio description is provided for all prerecorded video content.
Sign language interpretation is provided for all prerecorded audio content.
Frequently asked questions
What is the difference between captions and subtitles?
Captions and subtitles look similar but serve different audiences. Captions are written for people who cannot hear the audio: they include all spoken dialogue plus speaker identification and meaningful non-speech sounds — [applause], [phone rings], [ominous music]. Subtitles assume the viewer can hear but may not understand the language, so they translate dialogue only and leave out sound effects and music cues. WCAG 1.2.2 requires captions, not merely subtitles: a translated-dialogue-only subtitle track does not satisfy the criterion because a deaf viewer would miss the non-speech audio that carries meaning.
What is the difference between open and closed captions?
Closed captions are delivered as a separate track (for example a WebVTT file referenced by a <track> element) that the viewer can turn on or off, restyle, or switch between languages. Open captions are burned permanently into the video pixels and are always visible. Both can satisfy WCAG 1.2.2 as long as the captions are accurate, synchronized, and complete. Closed captions are usually preferred because they are searchable, resizable, and optional; open captions guarantee display on every player but cannot be turned off or restyled and degrade if the video is compressed.
Do auto-generated captions from YouTube or an AI tool meet 1.2.2?
Not on their own. Automatic speech recognition still misspells names and technical terms, drops or mis-punctuates sentences, guesses at homophones, rarely identifies who is speaking, and almost never labels non-speech sounds like music or applause. WCAG requires captions that are accurate and equivalent to the audio, so uncorrected auto-captions — sometimes called 'craptions' — generally fail. Auto-captions are a reasonable starting draft, but a human must review and correct the transcript, add speaker labels and non-speech descriptions, and fix the timing before the track is published.
What exactly must captions include to pass 1.2.2?
Captions must convey all of the audio information a hearing viewer receives. That means every word of dialogue and narration; identification of who is speaking whenever it is not obvious (for example [Narrator]: or [Dr. Lee]:); and meaningful non-speech audio such as sound effects, laughter, and music that carries information or mood — written as descriptions like [door slams], [audience laughs], or [tense music builds]. Captions must also be synchronized so text appears as the corresponding audio plays. Purely incidental sounds that carry no meaning can be omitted.
When does the media-alternative-for-text exception apply?
1.2.2 has a single exception: captions are not required when the synchronized media is itself a media alternative for text and is clearly labeled as such. In other words, if the video merely presents information that already exists as readable text on the same page — the video is an optional visual rendering of that text — captions are not required because a deaf user already has full access through the text. This exception is narrow and rarely applies; it does not cover ordinary videos whose content is not already available in text elsewhere on the page.
How is 1.2.2 different from 1.2.4 Captions (Live)?
1.2.2 covers prerecorded synchronized media — video that was produced and stored ahead of time, giving you the opportunity to write and time accurate captions before publishing. It is a Level A requirement. 1.2.4 Captions (Live) covers real-time content such as live webinars and broadcasts, where captions must be produced on the fly, and it is a Level AA requirement. If your video is recorded and then uploaded, 1.2.2 applies; if it streams live as it happens, 1.2.4 applies.