Video Accessibility Guide: Captions, Transcripts and WCAG Compliance

Video is now the default format for lectures, onboarding, product marketing and online courses. If those videos are not accessible, a meaningful part of your audience gets less of the message, or none of it. That includes people who are deaf or hard of hearing, blind or low-vision viewers, non-native speakers, and anyone watching on mute in a quiet office or on a train.

This guide is for educators, marketers and course creators who want a clear answer to three questions: what accessibility actually requires for video, how to produce captions and transcripts that meet the bar, and how to make it a repeatable part of publishing.

Captions, subtitles, transcripts and audio description

These four terms get mixed up constantly. They solve different problems.

Closed captions can be turned on and off by the viewer. Open captions are burned into the video image. Closed captions are generally preferred because viewers can control them and assistive technology can access them, while open captions are useful on platforms that do not support caption files.

A descriptive transcript goes a step further than a plain transcript by including descriptions of important visual information as well as the speech. It can serve as a media alternative for some content.

The WCAG success criteria that apply to video

The Web Content Accessibility Guidelines (WCAG) are the reference standard most laws and policies point to. Time-based media is covered under guideline 1.2. Here are the criteria that matter for most teams.

At Level AAA there are further criteria, such as sign language interpretation (1.2.6) and extended audio description (1.2.7), but most organizations target Level AA.

What this means in practice for a typical prerecorded course or marketing video at Level AA:

• Captions are required.
• Audio description is required if important information is only shown visually. (At Level A, a full text alternative can satisfy 1.2.3, but 1.2.5 at AA asks for audio description specifically.)
• Transcripts are required for audio-only content like podcasts, and strongly recommended for everything else.

There is a useful shortcut here: if the speaker describes what is on screen as part of the normal narration ("this chart shows sign-ups doubling after the price change"), there may be little left that needs separate description. Planning for this at the script stage is far cheaper than adding description later.

What "accurate" captions actually include

WCAG asks that captions provide an equivalent of the audio. Industry guidelines such as the DCMP Captioning Key and broadcast standards describe what that looks like. Good captions are:

• Accurate. The words match what was said, including names, product terms and jargon. Errors in key terms can change the meaning entirely.
• Complete. All meaningful speech is captioned from start to finish, not just the main speaker.
• Synchronized. Each caption appears when the words are spoken and stays on screen long enough to read.
• Speaker-identified. When it is not obvious who is talking, captions say so, for example "PRIYA:" or "[Narrator]".
• Inclusive of meaningful sounds. Sound cues that carry information go in brackets: [phone buzzing], [audience laughs], [upbeat music]. Background noise that adds nothing can be left out.
• Readable. Usually one or two lines at a time, broken at natural phrase boundaries, with standard punctuation and capitalization.
• Not obscuring key visuals. If on-screen text or a lower third would be covered, captions should move or the layout should leave space.

Why auto-captions need a human pass

Automatic speech recognition has improved enormously, and it is the right way to produce a first draft. It is rarely the right final product. Common problems include:

• Misheard proper nouns, brand names and technical terms.
• Missing or wrong punctuation, which makes captions hard to read and can change meaning.
• No speaker identification when people take turns.
• No sound cues at all.
• Worse accuracy with accents, crosstalk, background music and poor microphones.
• Timing drift, or captions that flash by too fast during quick speech.

The practical approach is to treat auto-captions as a draft that saves typing, then budget time to edit. Teams that publish a lot of video often keep a glossary of names and terms so editors can catch the same errors every time.

The legal landscape (high level)

Several laws and policies point to WCAG for digital content, including video. A few that come up most often:

• ADA Title II (United States). In 2024 the US Department of Justice published a rule requiring state and local government web content, including public colleges and universities, to meet WCAG 2.1 Level AA. The original rule set compliance dates in April 2026 and April 2027. In April 2026 the DOJ issued an interim final rule pushing each deadline back a year, to April 2027 for entities serving 50,000 or more people and April 2028 for smaller ones and special districts. The WCAG 2.1 AA requirement itself did not change. Deadlines can be revised again, so check the current status with your counsel.
• ADA Title III (United States). Covers businesses open to the public. There is no single technical regulation for websites, but courts and settlements frequently reference WCAG, and video captions are a common issue in complaints.
• Section 508 (United States). Requires federal agencies to make their information and communication technology accessible. Its standards incorporate WCAG 2.0 Level AA, and they affect vendors who sell to federal agencies.
• European Accessibility Act (European Union). Applies from June 2025 to a range of products and services, including e-commerce and some audiovisual media services, with the harmonized standard EN 301 549 referencing WCAG. How it applies depends on your sector and member state implementation.
• Other regions have their own rules, such as the Accessibility for Ontarians with Disabilities Act (AODA) in Canada. Many universities and companies also have internal policies stricter than the law.

Even where no law applies to you, captions and transcripts are worth doing for reach alone: many viewers watch with the sound off, and text makes your content searchable and easier to reuse.

A production workflow you can repeat

Accessibility is cheapest when it is part of the normal publishing process rather than a retrofit. Here is a workflow that works for a weekly lecture or a marketing team.

1. Plan in the script

Describe important visuals out loud. Read out on-screen text and URLs. Avoid "as you can see here" without saying what "here" is. This reduces or removes the need for separate audio description.

2. Record clean audio

Good microphones and quiet rooms improve both auto-caption accuracy and the viewer experience. Fewer errors mean less editing.

3. Generate a timed draft

Run the video through automatic speech recognition or a transcription service. Export a caption file with timestamps, typically WebVTT (.vtt) for web players or SRT (.srt) for most video platforms.

4. Edit for accuracy

Correct words and terms against your glossary, add speaker labels and sound cues, fix punctuation, and remove filler words only where doing so does not change meaning.

5. Check timing and line breaks

Watch the video with captions on. Fix captions that lag behind speech, disappear before they can be read, or break mid-phrase.

6. Publish captions and a transcript

Upload the caption file as closed captions, set the correct language, and publish the transcript on the same page as the video (or link to it right next to the player).

7. Add audio description if needed

If important visual information is still not conveyed in the audio, add an audio-described version or a descriptive transcript, depending on your WCAG target.

If you already publish to YouTube, you can pull the existing caption track as a starting point with YouTubeTranscript.dev's free subtitle downloader, then edit it into a clean transcript for your course page.

Caption quality checklist

Run through this before you publish:

1. Every spoken word that matters is captioned, start to finish.
2. Names, brands and technical terms are spelled correctly.
3. Speakers are identified whenever it is not visually obvious who is talking.
4. Meaningful sounds and music are noted in brackets.
5. Captions are in sync with the audio and stay on screen long enough to read.
6. Lines are broken at natural phrases, one or two lines at a time.
7. Captions do not cover important on-screen text.
8. The caption track is labeled with the right language.
9. A transcript is available next to the video.
10. Important visuals are described in the narration, an audio description track or a descriptive transcript.

Accessible player features to look for

Captions only help if people can use them. When you choose a video player or platform, check that it:

• Supports closed captions from standard files (WebVTT and SRT at minimum).
• Has a visible captions toggle, and ideally remembers the viewer's choice.
• Lets viewers adjust caption size, color and background for readability.
• Is fully operable by keyboard, with a visible focus indicator.
• Has labeled controls that screen readers announce correctly ("Play", "Mute", "Captions").
• Supports multiple audio tracks or a described version if you provide audio description.
• Does not autoplay with sound, or offers an easy way to pause and mute.
• Offers playback speed control, which helps many viewers follow along.

Accessible video is not a single feature. It is a habit: plan visuals into your narration, edit your captions, publish a transcript, and test the player. Do that for every video and compliance mostly takes care of itself.