Accessible Video & Media Players
A single video can fail three different groups at once — deaf viewers who cannot hear it, blind viewers who cannot see it, and keyboard users who cannot operate the player. Accessible media is a stack of parallel alternatives delivered through a second channel: captions, a transcript, audio description, and a player everyone can drive. This guide covers which ones your media owes, how to build each one properly, the HTML <video> and <track> elements, embedded YouTube and Vimeo players, and React — mapped to WCAG 2.2.
Why Media Is Where So Many Sites Fail
Text has one channel and it is easy to make accessible. Media has two channels running at once — a picture and a sound — and each one excludes a different group when it is the only way to get the information. The audio is unavailable to a deaf viewer. The picture is unavailable to a blind viewer. The controls are unavailable to anyone who cannot use a mouse. A video is, in effect, three accessibility problems wearing one costume, which is exactly why media is one of the most consistently failed areas of WCAG.
The way to keep it straight is to stop thinking about “the video” and start thinking about the information inside it, and the channels it travels through. Every piece of meaning in a video arrives as either sound or picture. Accessibility is the practice of making sure each of those pieces also arrives through a second channel for whoever cannot use the first: the audio becomes text (captions and transcripts), the essential picture becomes audio (audio description), and everything becomes text for people who use neither (a descriptive transcript).
This guide is framework-agnostic and works whether you drop in a native <video>, embed a YouTube player, or ship a React component. The requirements cluster around WCAG's 1.2 Time-based Media guideline, plus 1.4.2 Audio Control, 2.1.1 Keyboard, and 2.2.2 Pause, Stop, Hide for the player. We will start where you should always start: deciding what this particular piece of media actually owes.
The WCAG 2.2 Criteria Your Media Must Satisfy
| Criterion | Level | What your media must do |
|---|---|---|
| 1.2.1 Audio-only & Video-only | A | Provide a text transcript for prerecorded audio-only content, and an audio track or transcript for prerecorded video-only content. |
| 1.2.2 Captions (Prerecorded) | A | Synchronized captions for all prerecorded audio in video — dialogue, speaker identification, and meaningful non-speech sounds. |
| 1.2.3 Audio Description or Media Alternative | A | Either audio description of the essential visuals, or a full text alternative that conveys the whole video. |
| 1.2.4 Captions (Live) | AA | Real-time captions for live audio in synchronized media — live webinars, streams, and broadcasts. |
| 1.2.5 Audio Description (Prerecorded) | AA | Audio description for prerecorded video; at AA the text-alternative escape allowed by 1.2.3 no longer applies. |
| 1.4.2 Audio Control | A | Any audio that plays automatically for more than 3 seconds can be paused or stopped, or has a volume control independent of the system. |
| 2.1.1 Keyboard | A | Every player control — play, pause, seek, volume, captions, fullscreen — is fully operable by keyboard. |
| 2.2.2 Pause, Stop, Hide | A | Auto-playing video that lasts more than 5 seconds — including a muted, looping background video — can be paused, stopped, or hidden. |
| 4.1.2 Name, Role, Value | A | Custom player controls expose a name, a role, and their current state (playing or paused, muted, captions on or off) to assistive technology. |
The AAA tier goes further. Beyond AA, WCAG adds 1.2.6 Sign Language (a sign-language interpretation track), 1.2.7 Extended Audio Description (pausing the video to fit description when the gaps are too short), 1.2.8 Media Alternative (a full text alternative for all prerecorded media), and 1.2.9 Audio-only (Live). Most teams target AA, but a descriptive transcript — covered below — quietly gets you most of 1.2.8 for free.
Two criteria are failed far more than the rest. Captions (1.2.2) are the most often attempted but wrong — an auto-generated track left uncorrected — and audio description (1.2.5) is the most often skipped entirely, because teams do not realise their video carries information only the eyes can reach. This guide spends most of its length on those two.
1. Decide What This Media Owes
Before you write a caption or record a description, work out which alternatives this specific piece of media actually needs. The obligations are not one-size-fits-all — they fall out of two questions, and answering them turns a vague “make the video accessible” into a concrete checklist.
Question 1: Prerecorded or live?
Prerecorded media can be captioned, transcribed, and described in advance — so it owes the most. Live media can only realistically be captioned in real time (1.2.4); live audio description is not required at any level because it is so hard to produce on the fly.
Question 2: Where is the information?
Information in the audio needs a text equivalent (captions, transcript). Information in the picture that is not spoken needs an audio equivalent (audio description). Most videos carry some of both — so most videos owe both.
Run those two questions against what kind of media you have, and the requirements are mechanical:
| Media type | Example | What it owes (A / AA) |
|---|---|---|
| Audio-only (prerecorded) | Podcast, audio interview | A full text transcript (1.2.1). No captions and no description apply. |
| Video-only (prerecorded) | Silent animation, screen recording with no narration | A transcript or an audio track describing it (1.2.1). |
| Synchronized media (prerecorded) | A normal video with sound | Captions (1.2.2) + audio description (1.2.3 at A, 1.2.5 at AA). A transcript is strongly recommended. |
| Live synchronized media | Live webinar, streamed talk | Real-time captions (1.2.4 at AA). Live audio description is not required. |
The audio-description escape hatch — use it honestly. If a video carries noessential information visually that is not already in the soundtrack — a talking head who says everything they show — then no audio description is needed, and you have satisfied 1.2.3 and 1.2.5 with nothing to add. The test is: close your eyes and listen. If you can still follow everything that matters, you are done. Do not gold-plate a description onto a video that does not need one — but be ruthlessly honest about “essential.” On-screen text, charts, and silent demonstrations almost always count.
2. Captions: More Than the Words
Captions are the synchronized text of everything the soundtrack carries, shown in time with the video for someone who cannot hear it. The single most important thing to understand about captions is what separates them from subtitles.
Subtitles
Assume you can hear, and translate the dialogue into another language. Speech only. A same-language subtitle file is not captions and does not satisfy 1.2.2.
Captions
Assume you cannot hear, and carry everything the audio does: dialogue, who is speaking, and meaningful non-speech sounds — [phone rings], [ominous music]. This is what WCAG requires.
Good captions are verbatim, synchronized to the audio, identify the speaker when it is not obvious on screen, and describe the sounds that carry meaning — a knock at the door the characters react to, the sarcasm in a tone, the music that sets the mood. They are also paced to be readable: broken into short lines that stay on screen long enough to read.
Closed vs open captions
Closed captions are a separate track the viewer can turn on and off — the modern default, delivered as a WebVTT file via the <track> element or through a hosting platform. Open captions are burned permanently into the video pixels; they always show and cannot be styled or turned off, but they survive any player that lacks caption support. Prefer closed captions for the control they give the viewer; reach for open captions only when you cannot rely on the player to render a track.
The caption file: WebVTT
Closed captions are usually a WebVTT (.vtt) file — a plain-text list of time-stamped cues. It is readable and hand-editable, which is exactly how you fix an auto-generated draft.
WEBVTT
00:00:01.000 --> 00:00:04.000
[upbeat music]
00:00:04.500 --> 00:00:08.000
<v Dana>Welcome back. Today we're fixing
the checkout flow.</v>
00:00:08.500 --> 00:00:11.000
[keyboard clicking]
00:00:11.500 --> 00:00:14.000
<v Dana>Notice the error appears here —
right under the field.</v>The <v Speaker> voice tag identifies who is talking; square-bracket cues carry the non-speech sounds. This is the difference between a caption track and a subtitle track written out in a file.
Auto-captions are a draft, not compliance. Automatic speech recognition mishears names and technical terms, drops punctuation that changes meaning, never adds speaker labels or sound descriptions, and often drifts out of sync. WCAG 1.2.2 asks for captions that are accurate and complete. Use the machine track to save typing, then review every line, add the speaker IDs and the sounds, fix the timing, and upload the corrected file. Live captions (1.2.4) usually need a human real-time captioner (CART) for the same reason.
3. Transcripts: The Underrated Hero
Captions get the attention, but the transcript is the alternative that serves the most people for the least effort — and for audio-only content it is the requirement, not an extra. A transcript is a single block of text on the page containing everything the media conveys, readable without pressing play.
Look at who a transcript reaches that a caption track does not:
- Deafblind users who cannot see captions or hear audio, and read the transcript through a Braille display — the only channel that reaches them.
- People who cannot play media — on a locked-down work network, a slow connection, or a quiet room where sound is not an option.
- Skimmers and searchers who want to scan for one fact, quote a line, or Ctrl+F the content rather than scrub through a timeline.
- Search engines, which cannot watch a video but happily index a transcript — so the accessible choice is also the discoverable one.
The descriptive transcript is the one artifact that covers everything. A plain transcript captures the words; a descriptive transcript also writes out the essential visual information — the on-screen chart, the demonstration, the reaction. That single document serves as the transcript (1.2.1), as the full text alternative that satisfies audio description at level A (1.2.3), and as the media alternative at AAA (1.2.8). For a short explainer video, writing one good descriptive transcript is often less work than producing a separate audio description track.
Put the transcript on the page — visible, or one click away in a <details> disclosure right beside the player — not buried in a downloadable PDF or hosted off-site. It should carry speaker labels and, for a descriptive transcript, the visual notes clearly marked. The disclosure pattern is the same one the accordion & disclosure guide covers if you want it collapsible.
4. Audio Description: The Picture as Sound
Audio description is the mirror image of captions. Where captions turn the sound into text for people who cannot hear, audio description turns the essential picture into sound for people who cannot see. It is a narration, slotted into the natural pauses between dialogue, that describes the visual information the soundtrack leaves out — a graph that appears, a facial reaction, a caption on screen that no one reads aloud, a click that is shown but not narrated.
The trigger for needing it is the test from §1, restated: is there information in the picture that is not in the audio? A cooking video where the host narrates every step needs little or none; the same video where they silently add an unnamed ingredient needs a description of what went in. On-screen text, data, and demonstrations are the usual culprits.
1.2.3 at level A gives you a choice; 1.2.5 at AA takes it away
This is the part teams miss. 1.2.3 Audio Description or Media Alternative (level A) lets you satisfy the requirement either by adding audio description or by providing a full text alternative — a descriptive transcript — for the whole video. But 1.2.5 Audio Description (level AA) removes the text-alternative escape: at AA, actual audio description is required. So if your target is AA — as most legal frameworks and procurement requirements demand — a descriptive transcript alone is not enough for a video with essential visuals; you owe a real described version.
Standard vs extended description
Standard audio description fits inside the existing gaps between dialogue. Sometimes the gaps are too short to describe everything that matters — a fast, visually dense sequence. That is what 1.2.7 Extended Audio Description (AAA) addresses: the video pauses to let a longer description play, then resumes. You rarely need extended description if you plan the content to leave room for it — which is the real lesson.
How to deliver it in practice
- Script it into the production. The cheapest, most robust option: write the narration so the presenter says what they show (“I'm clicking the blue Save button in the top right”). Now the main soundtrack is the description and no extra track is needed.
- Offer a described version. Produce a second copy of the video with description mixed into the audio, and let the user choose it — a separate source, a toggle, or a second player.
- Add a descriptions track — with eyes open. A
<track kind="descriptions">WebVTT file is the standards-based route, but support for browsers and screen readers actually speaking it is still unreliable, and browsers will not pause the video for an over-long cue. Include it, but do not rely on it as your only delivery — verify in real assistive technology.
5. The Player: Keyboard, Autoplay, and Controls
Alternatives get the information out of the media; the player is how everyone operates it. The single best decision you can make here is to start with the native controls. A plain <video controls> gives you a play/pause button, a seek bar, volume, a captions menu, and fullscreen — all keyboard operable, all labelled, all maintained by the browser. You throw that away the moment you hide the native controls to build your own, and then you owe every piece of it back by hand.
If you build a custom player, you owe all of this
- Real buttons with accessible names. Every control is a
<button>with a text name — an icon alone is not a name. “Play”, “Mute”, “Captions”, “Fullscreen” (4.1.2). - Full keyboard operation. Every control is reachable by Tab and operable with Enter/Space; the seek bar is a real slider with arrow-key support. Nothing is mouse-only, and focus is never trapped (2.1.1).
- Visible focus. A clear focus indicator on each control, including over the video where contrast is unpredictable — see the focus management guide.
- State exposed, not just drawn. The play button announces whether it is playing or paused — swap the accessible name (“Play” ↔ “Pause”) or use
aria-pressed; the mute and captions toggles do the same. A colour or icon change alone is invisible to a screen reader (4.1.2, 1.4.1). - A captions toggle. If you replace the native controls, you also replace the native captions menu — so the player must offer its own way to turn captions on and off.
The keyboard mechanics — roving focus, a slider seek bar, managing focus as menus open — are the same disciplines covered in the keyboard accessibility and accessible slider guides. A custom player is one of the most control-heavy widgets you can build, which is the best argument for keeping the native one.
Autoplay: the two rules
1.4.2 Audio Control
If audio plays automatically for more than 3 seconds, the user must be able to pause/stop it or control its volume independently. Autoplaying sound with no off switch is a failure — and it talks over screen readers.
2.2.2 Pause, Stop, Hide
Auto-playing, moving content over 5 seconds — including a muted looping background video — must be pausable, stoppable, or hideable, because motion alone is a barrier for some users.
The simplest way to pass both: don't autoplay. Start paused and let the user press play. If a decorative background video must autoplay, mute it and give it a visible, keyboard-reachable pause control. Respect prefers-reduced-motionand don't autoplay for users who have asked the system to reduce motion.
6. The <video> Element in Practice
Here is a self-hosted video wired up the accessible way: native controls, a caption track, a descriptions track, no autoplay, and a transcript one click away.
<figure>
<video
controls
preload="metadata"
poster="/thumbnails/checkout-fix.jpg"
width="960"
playsinline
>
<source src="/video/checkout-fix.mp4" type="video/mp4" />
<source src="/video/checkout-fix.webm" type="video/webm" />
<!-- Reviewed, corrected captions (dialogue + sounds + speaker IDs) -->
<track
kind="captions"
src="/captions/checkout-fix.en.vtt"
srclang="en"
label="English"
default
/>
<!-- Audio description cues (support varies — verify in AT) -->
<track
kind="descriptions"
src="/descriptions/checkout-fix.en.vtt"
srclang="en"
label="English descriptions"
/>
<!-- Fallback for browsers with no video support -->
<p>
Your browser can't play this video.
<a href="/video/checkout-fix.mp4">Download it</a> or read the
<a href="#checkout-fix-transcript">transcript</a> below.
</p>
</video>
<figcaption>Fixing the checkout error flow (4:12).</figcaption>
</figure>
<!-- The transcript lives on the page, one click away -->
<details id="checkout-fix-transcript">
<summary>Read the transcript</summary>
<!-- Descriptive transcript: dialogue + on-screen visuals -->
</details>A few details earn their place. controls hands you the accessible native player. preload="metadata" and no autoplay keep the page quiet until the user acts. poster gives a still frame before play. The fallback content between the tags is a real text alternative for the rare browser that cannot play the video at all.
The <track> kinds
kind | What it carries | Notes |
|---|---|---|
captions | Dialogue + speaker IDs + non-speech sounds, same language. | What 1.2.2 requires. For people who cannot hear. |
subtitles | Dialogue translated to another language. | Assumes the viewer can hear; not a substitute for captions. |
descriptions | Text of the audio description, meant to be spoken by AT. | Standards-based but unreliably supported — verify; don't rely on it alone. |
chapters | Named sections for navigating the timeline. | Helpful for orientation and long videos. |
metadata | Data for scripts, not shown to users. | Not an accessibility feature by itself. |
Get the kind right — captions, not subtitles, for same-language text that includes the sounds — and set label and srclangso the player's menu names each track. The default attribute turns a track on by default; use it thoughtfully.
7. Embedded Players: YouTube, Vimeo, and Friends
Most teams do not host their own video — they embed a YouTube or Vimeo <iframe>. You do not control the platform's player chrome, but you are still responsible for the alternatives. Three things are squarely on you.
- Title the iframe. Give the embedding
<iframe>a descriptivetitle— “Video: fixing the checkout error flow” — so a screen reader user hears what the frame contains instead of “video player, frame”. - Upload your own captions. Do not trust the platform's automatic captions. Upload a reviewed caption file to the video so the captions are accurate and complete — the platform will happily serve your file instead of the machine one.
- Put the transcript on your page. The platform will not add a transcript to your page, and it is the alternative that serves the most people. Place a descriptive transcript near the embed.
<iframe
src="https://www.youtube-nocookie.com/embed/VIDEO_ID"
title="Video: fixing the checkout error flow"
allow="fullscreen"
loading="lazy"
></iframe>Beyond that, the player's own keyboard support is out of your hands, so test it: Tab into the embed and confirm play, volume, captions, and fullscreen are reachable and operable. If a platform's player is badly broken for keyboard or screen-reader users, the honest fallback is to self-host with a native <video> element you can fully control.
8. Accessible Media in React
In React the winning move is the same: render a native <video controls>, add the tracks, and pair it with a transcript disclosure generated from the same data — rather than rebuilding the player. Use useId to tie the figure and its transcript together without hard-coded ids.
function AccessibleVideo({ sources, captionsSrc, poster, caption, transcript }) {
const id = useId()
const transcriptId = id + "-transcript"
return (
<figure>
<video controls preload="metadata" poster={poster} playsInline width={960}>
{sources.map((s) => (
<source key={s.src} src={s.src} type={s.type} />
))}
{/* Reviewed captions — never the platform's auto track */}
<track
kind="captions"
src={captionsSrc}
srcLang="en"
label="English"
default
/>
<p>
Your browser can't play this video.{" "}
<a href={sources[0].src}>Download it</a> or read the{" "}
<a href={"#" + transcriptId}>transcript</a>.
</p>
</video>
<figcaption>{caption}</figcaption>
<details id={transcriptId}>
<summary>Read the transcript</summary>
{/* Descriptive transcript: dialogue + on-screen visuals */}
{transcript}
</details>
</figure>
)
}Two rules keep a React media component honest. First, do not mount the controls-less player and try to recreate the browser's work unless you truly must — and if you must, reach for a maintained accessible player (Vidstack, Plyr, or a wrapper around the native element) and still verify it. Second, keep the caption file and the transcript authored from the same reviewed source so they never disagree. The broader framework patterns are in the React, Vue, and Angular accessibility guides.
How to Test Accessible Media
A scanner can tell you a <track> element exists; it cannot tell you whether the captions are accurate or whether a blind user could follow the video. These hands-on checks are what actually matter, and each takes only a couple of minutes.
- Turn the sound off and watch. Read only the captions. Do they carry the dialogue, tell you who is speaking, and describe the meaningful sounds — or are they just the words, out of sync, with obvious errors? (1.2.2)
- Close your eyes and listen. Can you follow everything that matters from the soundtrack alone? If a visual moment leaves you lost, that is a missing audio description (1.2.5).
- Find the transcript. Is there one, on the page, near the player — and for a podcast or audio-only file, is it complete? (1.2.1)
- Put the mouse away. Tab to the player and operate every control — play, pause, seek, volume, captions, fullscreen — with the keyboard alone, with a visible focus indicator throughout (2.1.1).
- Run a screen reader over the controls. Each control should announce a name and its state — “Pause, button” when playing, “Captions on” when enabled — not “button” with no label. Use the NVDA or VoiceOver guides (4.1.2).
- Load the page and wait. Confirm nothing autoplays with sound, and any auto-playing motion can be paused (1.4.2, 2.2.2).
Layer automated checks on top for the mechanical issues — a missing iframe title, an unlabelled control — see automated vs manual testing, and scan the live page with the URL accessibility auditor. But the caption-quality and audio-description checks above are human judgement calls no tool can make for you.
Common Media Accessibility Mistakes & How to Fix Them
| Anti-pattern | Why it fails | The fix |
|---|---|---|
| Auto-generated captions are left on as the caption solution. | Machine captions mishear words, omit speaker IDs and sound effects, and drift out of sync — they are not accurate or complete captions (1.2.2). | Treat auto-captions as a draft: review every line, add speaker labels and non-speech sounds, fix timing, and upload the corrected file. |
| A same-language subtitle file is offered and labelled "captions". | Subtitles carry only dialogue; a deaf viewer misses the [door slams] and [tense music] that hearing viewers rely on to follow the scene (1.2.2). | Write true captions — dialogue plus speaker identification plus meaningful non-speech sounds — using kind="captions", not kind="subtitles". |
| The video autoplays with sound, or a background video loops with no pause control. | Autoplaying audio talks over screen readers and has no off switch (1.4.2); a moving background over five seconds cannot be paused (2.2.2). | Start paused. If a decorative background video must autoplay, mute it and provide a visible, keyboard-reachable pause control. |
| Custom player controls are icon-only <div>s with onclick handlers. | They have no accessible name, no role, no state, and cannot be reached or operated by keyboard (2.1.1, 4.1.2). | Use real <button> elements with text accessible names, keyboard operation, visible focus, and state exposed (playing/paused, muted, captions on). |
| A video with essential on-screen-only information ships with no audio description. | A blind viewer cannot access the chart, the silent demonstration, or the on-screen text that the soundtrack never mentions (1.2.3, 1.2.5). | Add audio description of the essential visuals — scripted into the soundtrack or as a described version — or, at level A only, a full text alternative. |
| A podcast or audio-only recording is published with no transcript. | Deaf and deafblind users, skimmers, and search engines get nothing; audio-only content has no captions to fall back on (1.2.1). | Publish a full text transcript on the page, with speaker labels, near the audio player — not only as an off-site or downloadable file. |
Accessible Media Checklist
- Alternatives scoped. You have decided what this media owes from its type (prerecorded/live) and where its information lives (audio/picture).
- Captions, done right. Prerecorded video has accurate, synchronized captions with speaker IDs and non-speech sounds — not raw auto-captions, not same-language subtitles (1.2.2).
- Transcript on the page. A text transcript is available near the media; audio-only content has one as its primary alternative (1.2.1).
- Audio description where needed. Video with essential on-screen-only information has audio description; at AA that means a real described version, not just a text alternative (1.2.5).
- Live media captioned. Live audio in synchronized media has real-time captions, planned before the event (1.2.4).
- Keyboard-operable player. Every control works by keyboard with visible focus; custom controls expose a name and state (2.1.1, 4.1.2).
- No hostile autoplay. Nothing autoplays with sound; any auto-playing motion over five seconds can be paused (1.4.2, 2.2.2).
- Embeds titled and tested. Any
<iframe>has a descriptive title, uses your own reviewed captions, and its keyboard support has been checked.
Work through the full WCAG 2.2 checklist to see media alongside every other requirement, and the keyboard accessibility guide for the player controls in depth.
Check Your Media on a Live Page
Scan any page with our free axe-core-powered auditor to catch an untitled video iframe, an unlabelled player control, or a <video> with no caption track — then run the sound-off and eyes-closed tests above for the things no scanner can judge.
Frequently Asked Questions
What is the difference between captions and subtitles?▾
They look similar and are often confused, but they solve different problems for different people. Subtitles assume you can hear the audio and only need the dialogue in another language — they translate speech and nothing else. Captions assume you cannot hear the audio at all, so they carry everything the soundtrack does: the dialogue in the same language, who is speaking when it is not obvious, and the non-speech sounds that carry meaning — [phone rings], [ominous music], [laughter]. WCAG 1.2.2 requires captions, not subtitles. A common failure is shipping a same-language subtitle file, calling it captions, and leaving a deaf viewer to wonder why the tense scene has no explanation — because the [footsteps approaching] that a hearing viewer relies on was never written down. If your file only contains spoken words, it is subtitles; captions also describe the sounds.
Do auto-generated (YouTube) captions meet WCAG?▾
Not on their own. Automatic speech recognition has improved enormously, but WCAG 1.2.2 requires captions that are accurate and complete, and auto-captions routinely mishear technical terms, names, and homophones, drop punctuation that changes meaning, omit speaker identification entirely, and never transcribe the non-speech sounds captions are supposed to include. They are also often out of sync. Treat auto-captions as a first draft that saves you typing, not as a compliant caption track: review every line, fix the errors, add speaker labels and sound descriptions, and correct the timing. The nickname the disability community gives uncorrected machine captions — 'craptions' — exists for a reason. Upload your corrected file rather than leaving the automatic track live.
What is audio description and when do I actually need it?▾
Audio description is a narration, inserted into the natural pauses between dialogue, that describes the essential visual information a blind or low-vision viewer would otherwise miss — an on-screen chart, a character's reaction, text that appears without being read aloud, a demonstration that is shown but not narrated. You need it whenever the video conveys information visually that is not already in the soundtrack. The test is simple: close your eyes and listen. If you can still follow everything that matters, you do not need audio description for that video. If you find yourself thinking 'wait, what just happened?' at any point, that gap is exactly what audio description fills. A talking-head interview where everything important is spoken usually needs no description; a software demo where the presenter says 'and then you click here' while clicking silently absolutely does.
Do I need both captions and a transcript?▾
For a video with sound, captions are required (1.2.2) and a transcript is strongly recommended; for audio-only content like a podcast, a transcript is the requirement (1.2.1) and there are no captions to add. They serve overlapping but different audiences. Captions are synchronized with the video, so they work for someone watching in real time who cannot hear. A transcript is a single block of text on the page, which serves people who are deafblind and read it in Braille, people who want to skim or search the content, people on a slow connection or in a sound-off environment, and search engines — none of whom are served by a caption track locked inside the player. The most powerful single artifact is a descriptive transcript: the dialogue plus the important visual information, written out as text. That one document can satisfy the transcript need, act as the text alternative for audio description under 1.2.3, and give you SEO-friendly content for free.
Is the HTML <track kind="descriptions"> element enough for audio description?▾
It is the standards-based mechanism, but in practice its support is not yet dependable enough to rely on alone. The idea is elegant — a WebVTT file marked kind="descriptions" whose cues a screen reader speaks in the gaps — but browser and screen-reader support for actually announcing that track has historically been patchy and inconsistent, and browsers do not pause the video to fit a description that is too long for the gap. So while you can and should include a descriptions track, the reliable ways to deliver audio description today are to script the description into the production so it is part of the main soundtrack, or to offer a separate described version of the video (an alternate source or a second player) that the user can choose. Whichever you use, verify it in your target screen readers rather than assuming the track is read.
Does WCAG allow autoplaying video?▾
It allows it only under tight conditions, and the safest answer is: do not autoplay with sound, ever. Two criteria apply. WCAG 1.4.2 Audio Control says that if any audio plays automatically for more than three seconds, the user must be able to pause or stop it or control its volume independently of the system volume — autoplaying sound with no off switch is a straight failure. WCAG 2.2.2 Pause, Stop, Hide says that auto-playing, moving content lasting more than five seconds — which includes a silently looping background video — must be pausable, stoppable, or hideable. Autoplaying audio is also simply hostile: it talks over screen readers, startles people, and competes with whatever else the user is listening to. Start paused, let the user press play, and if you must autoplay a decorative background video, mute it and give it a visible pause control.
How do I make an embedded YouTube or Vimeo video accessible?▾
You are responsible for the alternatives even though you do not control the player. Three things are on you. First, give the embedding <iframe> a descriptive title attribute so screen reader users know what the frame contains rather than hearing 'video player, frame'. Second, do not trust the platform's automatic captions — upload your own reviewed caption file to the video so the captions are accurate and complete. Third, put a transcript on your own page near the embed, because the platform will not, and a transcript is the alternative that serves the most people. Beyond that, the platform's player controls and their keyboard support are outside your control, so test them: tab through the player, confirm play, volume, captions, and fullscreen are reachable and operable, and if the player is badly broken, consider hosting the video yourself with a native <video> element you can make accessible.
Are captions required for live video?▾
Yes. WCAG 1.2.4 Captions (Live) is a level AA requirement that live audio in synchronized media — a live webinar, a streamed conference talk, a town-hall broadcast — must be captioned in real time. In practice this is usually delivered by CART (Communication Access Real-time Translation), where a trained human captioner types or re-speaks the audio into a live caption stream, because automatic speech recognition rarely reaches the accuracy WCAG requires, especially with multiple speakers, cross-talk, accents, or specialist vocabulary. Live audio description is not required at any WCAG level, which is a deliberate acknowledgement of how hard it is to produce in real time. Plan live captioning before the event, not after — you cannot retrofit real-time captions once the stream has ended, though you should also publish a corrected transcript or captioned recording afterward.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences