Video captions and transcripts (WCAG 1.2)

Captions are synchronized text for the speech and other sounds a viewer needs, shown with the video. According to W3C's captions page, they serve people who are Deaf or hard of hearing, others who cannot hear the audio, and people who process written information better than speech. A transcript is a separate text version of the audio, and a descriptive transcript adds the visual information too. W3C's guide to accessible audio and video gives these definitions and treats captions, transcripts, audio description and the media player as separate parts of one job.

Guideline 1.2 of WCAG, Time-based Media, sorts the cases: each criterion applies to one kind of media, prerecorded or live, with or without sound or picture. This page sorts out what each kind needs, how to add captions and transcripts, and how to check them. For the text under a photo, see captions versus alt text instead.

What WCAG asks for, by kind of media

Sort your media into the rows below. The table follows W3C's breakdown on its captions page and its transcripts page. Our conformance levels page explains Levels A, AA and AAA, and the criteria reference lists all of guideline 1.2.

Level AAA adds a full text alternative for video with sound (1.2.8), sign language (1.2.6) and extended audio description (1.2.7). Beyond silent video, two cases need no captions. One is media that only repeats text on the page and is clearly labeled as such, a media alternative for text, according to the Understanding document for 1.2.2. The other is a video whose only sound is background music, which W3C's captions page says has no important audio content. In our reading, when you are unsure whether the audio matters, caption it.

Captions, subtitles and transcripts: what each one is

• Captions are a text version of the speech and the non-speech sounds needed to understand the content, synchronized with the audio and in the same language. Closed captions can be turned on and off in the player. Open captions cannot be turned off.
• Subtitles is W3C's word for spoken audio translated into another language, and it says they are not directly an accessibility accommodation. Some regions use the word for captions too, so check what a vendor means.
• A basic transcript is a text version of the speech and non-speech sounds. A descriptive transcript adds the visual information, such as on-screen text and actions. W3C says descriptive transcripts are required to give video to people who are both Deaf and blind.
• Audio description is narration of the important visual details the soundtrack does not carry. It serves people who cannot see the video and is a separate requirement.

Captions and transcripts contain the same speech, so one can be built from the other. A transcript made from captions still needs the visual information added, such as speaker names and on-screen text, W3C notes.

Podcasts, audio clips and silent video

Criterion 1.2.1 Audio-only and Video-only (Prerecorded) is Level A. For recorded audio with no picture it asks for an alternative with equivalent information, in practice a transcript. W3C's example is a press conference whose transcript is a verbatim record of what the speakers say, identifies who is speaking and notes other significant sounds, such as applause and laughter. Put the link to the transcript immediately after the link to the audio, as that document's example for an audio clip does.

For recorded video with no sound, such as a silent screen recording, 1.2.1 asks for either a text alternative that describes what happens on screen, in sequence, or an audio track that gives the same information. The exception is media that adds nothing to the text around it, such as W3C's example of an engine animation inside a tutorial that already explains it in full.

Do automatic captions count?

W3C's captions page says automatically generated captions do not meet user needs or accessibility requirements unless they are confirmed to be fully accurate, and usually need significant editing. Its example is a recipe: a spoken instruction to broil for four to five minutes becomes 45 minutes, and a warning not to preheat the oven becomes advice to preheat it.

Automatic output is still a useful starting point, as W3C says. Review every line against the audio, then add what a person has to judge: who is speaking and which non-speech sounds matter. The Understanding document for 1.2.2 lists failure F8, captions that omit some dialogue or important sound effects.

What good captions contain

W3C's guide to transcribing audio to text lists common practices, and says they are practices, not requirements:

• All speech and the sounds that matter. Identify speakers where it helps, and put relevant non-speech sounds, such as a crash, in parentheses.
• Music only when it matters, described in objective terms.
• No rewriting. Do not correct grammar, censor or add clarifications, and use [unintelligible] where speech cannot be understood.
• Short lines. One or two lines per caption, generally under 32 characters per line, a new sentence on a new line, and long sentences broken at a logical phrase.

Captions must also be synchronized with the audio, and WCAG's definition of captions adds that they should not obscure relevant information in the video, so check them against on-screen text.

How to add captions and a transcript

Video you host yourself

Make a caption file and attach it to the video with a track element. W3C's captions page says WebVTT is the most common caption format on the web, and lists SRT and TTML as others. W3C's technique H95 shows the pattern and lists it as sufficient for 1.2.2 when used with closed captions:

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

WEBVTT

00:00:00.000 --> 00:00:03.000
<v Host>Welcome to the tour.

00:00:03.000 --> 00:00:05.000
(door closing)

The first block is the page markup and the second is the contents of tour-en.vtt, the caption file. Set kind to captions. MDN says the default kind is subtitles when it is left out, and H95 says a subtitles track holding only dialogue is not enough when other audio matters to understanding the video.

Video in a platform's player

The track element is for HTML video and audio elements, so for an embedded platform player use that platform's caption tools instead. Edit any automatic captions before you publish, then play the embed on your page and confirm the player shows the captions. The iframe that holds an embedded player also needs a title, a check our methodology page lists under 4.1.2.

Transcripts

W3C's transcripts page says most transcripts on the web are HTML, and advises putting the transcript, or a link to it, right under the video, on the same page when the media is on your own site. Most caption editors export plain text, so start there, then add speaker names, on-screen text and descriptions of what is shown. W3C's example descriptive transcript is a table with an audio column and a visual column. Text also helps search, as the Understanding document for 1.2.1 notes.

Check the player, not only the files

Captions help nobody if the player will not show them. W3C's media player page says most browsers' default players have limited accessibility functionality, and that most organizations use an existing player with good accessibility support instead of coding one. Controls need keyboard support, a visible focus indicator, clear labels and enough contrast. Test yours with our keyboard accessibility test. Audio that starts on its own is a separate problem (WCAG 1.4.2 Audio Control), and moving content has its own guide, animation and reduced motion.

Live video and live captions

Success criterion 1.2.4 Captions (Live) is Level AA and applies to live video with sound, such as a webinar or a stream. W3C's captions page says live captions are usually produced by professional real-time captioners or Communication Access Realtime Translation (CART) providers, who can work remotely over a phone or internet connection. The Understanding document says the criterion does not require every two-way call through a web app to be captioned regardless of user needs: responsibility falls on the callers or the host caller, not the application.

A posted recording is prerecorded media. WCAG defines prerecorded as information that is not live, so in our reading 1.2.2 applies to it, and W3C says a recording of a live-captioned event will probably need minor editing for accuracy.

Which laws and rules ask for captions

For web content, the rules below name a WCAG version instead of listing captions themselves, and guideline 1.2 does the listing. This page is general information, not legal advice. For who is covered, see our accessibility laws pages and the which accessibility laws apply to me questionnaire.

The ADA row covers state and local governments only; for businesses open to the public, see our ADA website compliance guide. For the European Union, see our pages on the European Accessibility Act and EN 301 549. An exemption changes what a law requires of you, not what viewers need.

Check it yourself

Review each video on a page:

1. List the media. Find every video and audio player, including embeds, and mark each as prerecorded or live, with or without sound.
2. Watch twice. First with sound off and captions on: can you follow it? Then with sound on, reading along: every line of speech, speaker changes, the sounds that matter, timing that keeps up, and captions that do not cover on-screen text.
3. Find the transcript. It should be right under the video or linked there, with the visual information if it is meant to be descriptive.
4. Use the player with the keyboard. Play, pause, volume, the captions control and full screen should work, with focus visible.
5. Rehearse live events, and caption the recording you post afterward.

Record the result in the free WCAG audit checklist, which tracks all 55 Level A and AA criteria, including 1.2.1 to 1.2.5, with a status and notes for each, and downloads the audit as a CSV file. Our guide to testing website accessibility puts this check beside the others.

GotAlt's checks do not look for captions or transcripts. Whether captions are accurate and keep up with the audio takes a person watching and listening. Scan my site for free still flags audio or video set to autoplay with sound, and iframes with no title, which includes an embedded player's iframe. The methodology page lists every rule.

If you cannot caption everything at once, keep a list of what is missing, start with the newest and most-viewed videos, and say so in your accessibility statement in plain words such as "some videos do not have captions". That is our suggestion, and it records a gap rather than closing it.