Captions for Recorded Video Under the ADA

Captions, subtitles and transcripts: what is the difference?

A school district posts a recording of its board meeting. A parent who is deaf opens it and sees people talking. Without captions the recording is a silent film.

WCAG 1.2.2 (Level A) requires captions for all prerecorded audio content in synchronized media, meaning video that has a soundtrack. The only exception is media that is an alternative for text and is clearly labeled as such.

• Captions present the dialogue and also identify speakers and meaningful non-speech sounds: applause, a gavel, an alarm.
• Subtitles usually assume the viewer can hear and only render the speech, often in another language. A subtitle-only track can fall short of this criterion.
• A transcript is a separate text document. It helps, but it does not replace captions synchronized with the picture.

Captions can be open (burned into the picture) or closed (a track viewers switch on). Both satisfy the criterion; closed captions let viewers restyle the text.

Adding captions to a recorded board meeting

Start with the video element. A caption track is a separate file linked from the video.

<video controls src="/media/board-2026-05-14.mp4"></video>

<video controls src="/media/board-2026-05-14.mp4">
  <track kind="captions"
         src="/media/board-2026-05-14.en.vtt"
         srclang="en" label="English captions">
</video>

The file matters as much as the markup. A track that is only a stream of lowercase words, with no speakers and no sounds, passes a tool and fails a person.

WEBVTT

00:00:02.000 --> 00:00:05.000
we'll start with public comment

00:00:05.500 --> 00:00:09.000
thank you madam chair

WEBVTT

00:00:02.000 --> 00:00:05.000
CHAIR OKAFOR: We'll start with public comment.

00:00:05.500 --> 00:00:08.000
[Applause]

00:00:08.500 --> 00:00:11.000
SPEAKER: Thank you, Madam Chair.

Custom players frequently hide the captions switch. If you replace the native controls, rebuild this one.

<video id="v" src="board.mp4">
  <track kind="captions" src="board.en.vtt" srclang="en" label="English">
</video>
<button id="play">Play</button>
<button id="mute">Mute</button>

<video id="v" src="board.mp4">
  <track kind="captions" src="board.en.vtt" srclang="en" label="English">
</video>
<button id="play">Play</button>
<button id="mute">Mute</button>
<button id="cc" aria-pressed="false">Captions</button>
<script>
const video = document.getElementById('v');
document.getElementById('play').addEventListener('click', () => {
  video.paused ? video.play() : video.pause();
});
document.getElementById('mute').addEventListener('click', () => {
  video.muted = !video.muted;
});
const track = video.textTracks[0];
track.mode = 'hidden';
document.getElementById('cc').addEventListener('click', e => {
  const on = track.mode !== 'showing';
  track.mode = on ? 'showing' : 'hidden';
  e.currentTarget.setAttribute('aria-pressed', String(on));
});
</script>

Where recorded video on public sites goes wrong

Public bodies produce a steady stream of video: meeting recordings, "how to apply" walkthroughs, safety announcements and recorded webinars. The usual failures are a video with no track at all, a track generated by speech recognition that was never read through, and videos hosted by a vendor whose player has no captions button. The Department of Justice's guidance lists videos without captions among the common barriers on state and local government sites.

Auto-generated captions are a starting point. Proper names, addresses and numbers (a hearing date, a phone number) are exactly where they fail, and exactly what a resident needs to get right. Vendor-hosted players are a frequent source of the problem; see vendors and third-party content.

Players on phones and tablets

Native apps that play recorded video need the same captions. The built-in iOS and Android players can show caption and subtitle tracks that you supply, so the main work is producing a correct caption file and making sure your own controls expose the switch; no separate code is needed for the criterion itself.

What a good caption file contains

• All speech, verbatim enough to preserve meaning, with correct names, numbers and terms.
• Speaker names when the speaker is off screen or the voice changes.
• Sounds that matter to understanding, in brackets: [Alarm sounds], [Phone rings].
• Timing close to the speech, and lines short enough to read before they vanish.
• Placement that does not cover on-screen text such as a phone number in a lower third.

Testing: watch it with the sound off

1. Mute the video and switch on captions. Can you follow the whole thing, including who said what?
2. Find the captions control by keyboard only. Is it reachable and does it state whether captions are on?
3. Check three facts against the audio: a name, a number and a date.
4. Look at embedded third-party players too, in the same way.

Tools can see a track element; they cannot read the text for accuracy.

Mistakes to retire

• Publishing raw auto-captions.
• Offering only a transcript link and calling the video captioned.
• Captions that stop after the introduction.
• A caption file in the wrong language for the audio.
• Captions available in a player that does not appear on mobile.

Ship it when

• Every prerecorded video with sound has captions that were reviewed by a person.
• The captions switch is operable by keyboard and touch.
• Speakers and meaningful sounds are identified.

Sources

• Understanding SC 1.2.2: Captions (Prerecorded) (W3C), opens in a new tab
• G87: Providing closed captions (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.