Video Accessibility: Captions, Transcripts and Audio Description Explained

Video accessibility means people can get the same information from your video whether or not they can hear it, see it, or use a mouse. In practice that comes down to four things: accurate captions for speech and important sounds, a way to get the visual information (audio description or a descriptive transcript), a media player that works with a keyboard and a screen reader, and no autoplaying audio or flashing that people can't stop.

For Ontario organizations covered by the AODA, the legal minimum for prerecorded video on your website is captions plus either audio description or a text alternative that covers what's shown on screen. The AODA's standard exempts live captions and the stricter audio description criterion, but it doesn't exempt the rest.

This guide covers the WCAG success criteria for audio and video, exactly what the AODA exempts, how captions differ from subtitles and transcripts, why auto-captions are a starting point rather than a finish line, and what to check in your player.

WCAG video accessibility requirements at a glance

WCAG groups the media requirements under guideline 1.2, Time-based Media. These five criteria cover Levels A and AA. All five were in WCAG 2.0 and are unchanged in WCAG 2.2.

Four more criteria (1.2.6 to 1.2.9, covering sign language, extended audio description, full media alternatives and live audio-only content) are Level AAA. Few laws require them, but they're worth considering for video aimed at Deaf or blind audiences.

What the AODA requires for video captions and description

Section 14 of the Integrated Accessibility Standards Regulation (O. Reg. 191/11) requires designated public sector organizations and large organizations (50 or more employees in Ontario) to make their websites and web content conform with WCAG 2.0 Level AA, "other than" success criteria 1.2.4 Captions (Live) and 1.2.5 Audio Descriptions (Pre-recorded). You can read the text in the Integrated Accessibility Standards on Ontario's e-Laws site, and our AODA requirements overview covers who it applies to and the related deadlines.

For video on a covered website, that leaves you with:

• Captions on every prerecorded video with sound (1.2.2). This is the one organizations most often miss.
• Audio description or a descriptive transcript (1.2.3). Because 1.2.5 is exempt, a text alternative that describes the visuals is enough to meet the AODA minimum.
• Transcripts for audio-only content such as podcasts (1.2.1).

Two cautions. First, a live webinar that you record and post afterwards is no longer live. Once it's on your site as a recording, it's prerecorded video and needs captions. Second, the exemptions are a legal floor, not a recommendation. Live captions are still what Deaf and hard-of-hearing attendees need to follow a live event, and procurement requirements that ask for full WCAG Level AA include both exempted criteria.

Captions vs subtitles vs transcripts

These terms get used interchangeably, but they do different jobs. The W3C notes that "captions" and "subtitles" mean the same thing in some parts of the world. In Canada and the US, the usual distinction is this:

Closed and open captions

Closed captions can be turned on and off by the viewer and are usually supplied as a separate file. Open captions are burned into the video image and always visible. Closed captions are the better default for your website because viewers can resize or restyle them in many players and screen readers can access the text. Open captions are useful on social platforms where videos autoplay muted.

Transcripts don't replace captions

A transcript on its own doesn't meet 1.2.2 for a video with sound, because captions need to be synchronized with what's on screen. A descriptive transcript can, however, meet 1.2.3, and it's the simplest route to the AODA minimum for visual content.

Video captions and WCAG: what good captions include

WCAG doesn't set a percentage accuracy target, but captions that are wrong don't provide the information the audio does. Good captions:

• Match what's said, including names, product terms and numbers.
• Identify speakers when it isn't obvious who's talking.
• Include sounds that matter to understanding, such as [phone rings] or [audience laughs], and describe music when it carries meaning.
• Stay in sync with the speech and on screen long enough to read.
• Don't cover on-screen text such as names, titles or slide content.

On your own site, captions are usually a WebVTT file attached to the video. A short sample:

WEBVTT

00:00:01.000 --> 00:00:04.500
<v Priya>Welcome to our clinic's virtual tour.

00:00:05.000 --> 00:00:07.000
[door chime]

00:00:07.200 --> 00:00:10.000
<v Priya>This is the accessible entrance on Queen Street.

Are auto-captions good enough?

Not as they come. The W3C's guidance on captions says automatically generated captions don't meet user needs or accessibility requirements unless they're confirmed to be fully accurate, and that they usually need significant editing. The errors aren't random. Auto-captions tend to stumble on names, technical terms, accents and overlapping speech, and they rarely add speaker labels or sound cues. A single missed word like "not" can reverse the meaning of a sentence.

The practical workflow is to generate captions automatically, then have a person review them against the audio, fix errors, add speaker names and sound cues, and publish the corrected file. For a short marketing video that's a modest amount of editing.

Audio description requirements

Audio description is narration that tells blind and low-vision viewers what's happening on screen when the soundtrack doesn't. In Canadian broadcasting, it's often called described video. It matters most when the visuals carry information that isn't spoken: on-screen text, a chart, a demonstration, a change of location.

You can often avoid the need for a separate description track by describing as you go. If the presenter says "As you can see on this chart, bookings rose 20 percent in March" instead of "As you can see here", the information is already in the audio.

Talking-head video: Usually needs no description beyond a mention of the speaker's name and title, if those appear only as on-screen text.
Product demo with silent screen recordings: Needs description of each step shown, either as narration or in a descriptive transcript.

Accessible media players

Perfect captions don't help if someone can't turn them on. The player is part of your web content and has to meet WCAG too. Check that:

• Every control (play, pause, volume, captions, full screen) works with the keyboard alone (2.1.1), with a visible focus indicator (2.4.7).
• Controls have accessible names a screen reader can announce, such as "Play" rather than "button" (4.1.2).
• The captions button is easy to find and remembers the viewer's choice if possible.
• Embedded players in an iframe have a descriptive title attribute.

The native HTML <video> element with the controls attribute is a reasonable baseline, though browsers vary in how accessible their default controls are. A minimal example:

<video controls preload="metadata">
  <source src="clinic-tour.mp4" type="video/mp4">
  <track kind="captions" src="clinic-tour.en.vtt"
         srclang="en" label="English" default>
</video>
<p><a href="clinic-tour-transcript.html">Read the clinic tour transcript</a></p>

<iframe src="https://www.youtube.com/embed/VIDEO_ID"
        title="Virtual tour of our accessible clinic"></iframe>

Test the player with only a keyboard before publishing. Our keyboard accessibility guide covers what to look for.

Autoplay, motion and flashing

Autoplay and audio (1.4.2 and 2.2.2)

If audio plays automatically for more than three seconds, users need a way to pause or stop it, or to control its volume separately from the system volume (1.4.2, Level A). Autoplaying sound is a serious problem for screen reader users, whose speech output gets drowned out before they can find the pause button. The simplest fix is not to autoplay video with sound.

Silent background videos in page headers fall under 2.2.2 Pause, Stop, Hide (Level A): moving content that starts automatically, lasts more than five seconds and is shown alongside other content needs a way to pause, stop or hide it. Add a visible pause button, and consider respecting the prefers-reduced-motion setting by not starting the video at all.

Flashing (2.3.1)

Content must not flash more than three times in any one-second period unless the flashes are below WCAG's general and red flash thresholds (2.3.1, Level A). Flashing can trigger seizures, so this one isn't a matter of convenience. Watch for strobe effects, rapid cuts between light and dark scenes, and flashing transitions in promotional videos.

Video accessibility checklist

• Every prerecorded video with sound has accurate, human-reviewed closed captions.
• Captions identify speakers and include meaningful sounds.
• Visual information is spoken in the video, described, or covered in a descriptive transcript.
• Podcasts and other audio-only content have transcripts.
• Recorded webinars posted to your site have captions.
• Player controls work by keyboard, have visible focus and accessible names.
• Embedded iframes have a descriptive title.
• Nothing autoplays with sound; background video can be paused.
• Nothing flashes more than three times per second.

An automated tool can find a <video> without a captions track or an iframe without a title, but it can't tell you whether the captions are accurate or the description is adequate. Our article on automated vs manual accessibility testing explains where each fits, and you can start with a free automated scan of your site.

Frequently asked questions