Does your video have captions?

The one accessibility artefact nobody ships by accident

Most accessibility defects are cheap to fix once you know they are there. Alt text is a sentence. A form label is an attribute. A heading is a tag. A caption track is different: it is a separate timed file, per video, that somebody has to sit down and make. Which is why it is the criterion a site fails almost by default, and why the failure is so quiet — a <video src="demo.mp4" controls> with no <track> inside it is complete, valid HTML. No linter warns. No framework warns. No build step fails. The page looks finished, because in every sense except the one that matters to a deaf visitor, it is.

We ran this checker over public pages while building it. The one that says the most: W3Schools’ own tutorial page for the <video> element — the page millions of developers learn the tag from — serves two unmuted videos with zero caption tracks between them. That is not a criticism of a tutorial, it is the shape of the problem. The canonical example of how to embed a video does not include a caption track, so neither does the code copied from it.

The second thing this finds is louder and simpler. Audio that starts on its own, unmuted, with no controls is a level A failure under SC 1.4.2 — and it is the single defect a screen reader user cannot work around, because the way they would find your stop button is by listening to the page, and your audio is what they cannot hear over.

What this checker refuses to call a failure

Media is the category where a captions checker cries wolf loudest, because the most common <video> on the marketing web is the muted hero loop — and it has no audio to caption. A tool that counts <track> elements reports every one of those as a level A violation, and an owner who checks the first two and finds them wrong never reads the third. So four things are called failures here. Everything else is reported, argued, and kept out of the count.

A muted video is never a captions failure. Read live while building this, Apple’s homepage served two muted product videos and Notion’s served one: correct markup, nothing owed under SC 1.2.2, and all three are listed here under the question that does apply to them — whether a silent video that shows you something needs a text alternative, and whether a loop that never stops needs a pause control.

A hosted embed is never guessed at. A YouTube, Vimeo, Wistia or Loom player keeps its track list behind its own API, so nothing in your HTML can say whether it is captioned. It is listed with the two-click way to check it by hand. What we can read — whether the iframe has an accessible name — is read, and an unnamed player is a real SC 4.1.2 failure.

kind="subtitles" is review, not a failure. The distinction from captions is real under WCAG, and the attribute cannot prove which one your file contains — it is the HTML default, and plenty of fully captioned videos ship with it. Same for a missing controls attribute, which usually means a custom player rather than an uncontrollable one, and for a missing audio description, which SC 1.2.3 lets you satisfy with a transcript instead.

The fix, in full

Before — valid HTML, no warning anywhere, and unusable without sound:

<video src="/media/demo.mp4" autoplay loop></video>

After:

<video controls poster="/media/demo.jpg">
  <source src="/media/demo.mp4" type="video/mp4">
  <track kind="captions"
         src="/media/demo.en.vtt"
         srclang="en"
         label="English"
         default>
</video>
<p><a href="/media/demo-transcript">Read the transcript</a></p>

Four changes, and each one answers a criterion. controls instead of autoplay loop answers SC 1.4.2 and SC 2.2.2 at once — nothing starts by itself, and the browser’s own player is keyboard accessible for free. The <track> answers SC 1.2.2. The transcript link answers SC 1.2.3 for a product video whose narration already describes what is on screen, and it is the cheapest indexable text you will ever add to the page — an eight-minute demo is a thousand words that currently do not exist for a crawler either.

The .vtt file itself is plain text: a timestamp line and the words spoken between those times. Generate the first pass automatically, then read it once against the audio and fix the names, the product terms and the numbers — the words machine captioning gets wrong are precisely the ones carrying the meaning, which is why WCAG does not accept auto-captions as captions.

Common questions

What does a video accessibility checker check?

Whether the video on your page can be used by someone who cannot hear it, and whether anything on the page starts talking without being asked. It reads every <video>, <audio> and known player <iframe> the page serves and answers four questions about each: is there a caption track, does that track name a file, does audio start on its own with no way to stop it, and does an embedded player have a name. Each failure is named under the WCAG 2.1 criterion it sits on — SC 1.2.2 Captions at level A, SC 1.4.2 Audio Control at level A, SC 4.1.2 Name Role Value at level A.

Why do captions get missed when alt text doesn't?

Because a caption track has to be authored. Alt text is a sentence someone types into a CMS field; a header cell is a tag swap; a form label is an attribute. A caption file is a separate timed document per video, and nobody produces one by accident. Meanwhile the markup gives no hint that it is missing: <video src="demo.mp4" controls> is complete, valid HTML that no linter, no framework and no build step will ever warn about. The page looks finished because it is finished, in every sense except the one that matters to a deaf visitor.

My video is a silent background loop. Do I need captions?

No, and this checker will not tell you that you do. A muted <video> has no audible track by definition, so SC 1.2.2 does not reach it. What does reach it is SC 2.2.2 Pause, Stop, Hide: moving content that starts automatically and runs more than five seconds needs a way to pause, stop or hide it, and a loop runs forever. So a muted autoplay loop is reported here for review under that criterion, never as a captions failure. And if the silent video actually SHOWS something — a workflow, a number, a demo — then it is video-only content carrying information, and SC 1.2.1 asks for a text alternative.

Can you tell whether my YouTube embed has captions?

No, and no tool reading your HTML can. The track list lives inside the player, behind YouTube's own API, so the only honest answer is to list the embed and tell you where to look. Guessing would be wrong in both directions: plenty of embeds are fully captioned, and plenty of channels are relying on YouTube's automatic captions — which WCAG does not accept, because they are unreviewed machine output and the criterion asks for an accurate synchronised alternative. What we can read about that iframe is whether it has an accessible name, and that is a real level A failure when it is missing.

Are subtitles the same as captions?

Not under WCAG. Subtitles assume you can hear and are translating the dialogue. Captions are for someone who cannot hear, so they also carry the non-speech audio: who is speaking, the phone ringing, the laugh that makes the next line land. The complication is that kind="subtitles" is the default value in HTML, and a great many correctly captioned videos ship their caption file with it. The markup cannot prove which one your .vtt contains, so a subtitles-only video is reported for review here and never counted as a failure.

Do auto-generated captions count?

Not on their own. SC 1.2.2 asks for captions, and the Understanding document is explicit that they have to be accurate and synchronised — automatic speech recognition mishears exactly the words that carry the most meaning, which is names, products, jargon and numbers. The practical route is the cheap one: generate the first draft automatically, then read it against the audio once and fix it. That is minutes per video, and it is the difference between a file that exists and a file that conforms.

Why is autoplay with sound singled out?

Because it is the one defect that stops a screen reader user from finding the fix. Their synthesised speech is now competing with your audio, and the way they would normally locate your stop button is by listening to the page — which is what your audio is drowning out. SC 1.4.2 is level A and applies to anything that plays for more than three seconds. This checker calls it a failure only when autoplay is present with no muted attribute and no controls, which is also markup every modern browser already blocks, so it is usually code that has never been tested in the browser it ships to.

What about audio description?

SC 1.2.3 (level A) and SC 1.2.5 (level AA) cover what is only shown on screen — the cursor moving through your product, the number appearing in the chart — for a visitor who cannot see it. This checker reports a captioned video with no descriptions track and no transcript link for review, not as a failure, because SC 1.2.3 can be met with a text alternative on the page and many conforming sites do exactly that. The cheapest structural fix is upstream: narrate what you are doing while you record, and the audio already describes the video.

My player is built by JavaScript. Will this see it?

Only if the <video> or the player iframe is in the HTML your server sends, which is what this reads — deliberately, because it is fast, free and the same markup a crawler sees. If the checker finds nothing on a page where you can watch something, that is itself the answer: the player arrives later. The free WCAG 2.1 AA scan renders each page in a real browser and will see it.

Does this store my domain?

No. The check is an HTTP GET of the page you name, run inside the request and discarded when it answers. There is no account, no email field and no row written anywhere. If you go on to run the free scan, that one does keep a report so you can come back to it, which is the whole point of a report.