Captions that meet accessibility standards
Updated
Captions and subtitles are not the same thing. Subtitles carry the dialogue for someone who cannot understand it; captions carry everything on the soundtrack that a viewer who cannot hear it would otherwise miss, including who is speaking and the sounds that are not speech. WCAG 1.2.2 requires captions on prerecorded video at level A. An automatic transcript gets you the dialogue, which is most of the words and none of the rest.
Subtitles carry dialogue, captions carry the soundtrack
The distinction is not pedantry. It is most of what accessibility work on a video consists of. A subtitle track assumes you can hear and clarifies the words. A caption track assumes you cannot, so it has to convey everything the audio was doing.
That means three things a speech model does not produce: identification of who is speaking when it is not obvious on screen, non-speech sounds that carry meaning, and an indication of tone where tone changes what a line means. A door slamming, a phone ringing, laughter from off camera, a line delivered sarcastically.
An automatic transcript is a subtitle track. Turning it into a caption track is manual work, and it is the part most auto-captioned video skips without saying so.
What the standard actually asks
The requirements people mean when they say WCAG compliance are narrower than the discussion around them suggests, and worth reading once.
- 1.2.2, captions for prerecorded audio in video, at level A. This is the baseline, and the one that applies to almost everything published
- 1.2.4, captions for live audio, at level AA. Live captioning is a different discipline and not something a browser tool addresses
- 1.2.3 and 1.2.5 cover audio description of visual content, which captions do not satisfy and no transcription tool produces
- 1.4.3 contrast applies to burned-in captions as rendered text, so the caption style has to survive a bright shot behind it
The timing rules, and the numbers behind them
Captions that are accurate and unreadable fail the person they were made for. The conventions are long established, and this tool enforces them rather than leaving them to judgement: at most 42 characters a line, at most 2 lines on screen, nothing shorter than 0.8333333333333334 seconds, and nothing faster than 17 characters a second.
Reading speed is the rule that matters most and is broken most often. 17 characters a second is a comfortable adult rate for English. A fast speaker transcribed verbatim routinely exceeds it, and well above that a viewer is choosing between reading the caption and watching the shot. Meeting the limit means cutting words, which feels wrong and is correct.
Every line here is checked against those four numbers and flagged if it fails, so the work is reviewing flags rather than counting characters. The flags are mechanical, which also means they say nothing about whether the words are right.
Burned in or a separate track, for accessibility specifically
A separate track is better, and this is the one place where the burn-in this tool exists to do is the wrong choice. A caption file can be turned off by someone who does not need it, restyled by someone who needs larger text, read by assistive software, indexed by a search engine, and corrected without re-encoding. Burned-in text does none of that.
Burn in when the destination will not carry a track. Short-form video platforms take one file, a video in a slide deck has no caption mechanism, and a file sent over a messaging app arrives as a file. There, burned-in captions are the accessible option, because the alternative is none.
Where you control the player, ship the track. Export WebVTT and attach it, and keep a burned-in version for the places that cannot read one.