← Back to Blog
Accessible video player with captions, audio description, and transcript icons

Video Accessibility Requirements


Here’s everything you need to make your video accessible — from captions to custom controls.

Provide captions (A, AA)

Ask the question: Does the video have speech or other audio that is needed to understand the content? If yes, you need captions. (WCAG 1.2.2)

You’ll need a properly formatted WebVTT file (.vtt).

A girl in a fur hat adds a .vtt caption file to a video on an old computer so the person who cannot hear can follow along

How to add captions

Add a <track> element with kind="captions" and a language tag:

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track src="captions_en.vtt" kind="captions" srclang="en" label="English" default>
</video>

A basic captions_en.vtt file looks like this:

WEBVTT

00:00:01.000 --> 00:00:04.000
[Narrator]: Welcome to the tutorial.

00:00:05.500 --> 00:00:09.000
Today we'll learn how to make
video content accessible.

00:00:10.000 --> 00:00:13.500
[background music]

Each cue has a timecode range and the text to display. Use square brackets for non-speech sounds like [background music] or speaker identification like [Narrator].

Closed captions vs. Open captions

There are two ways captions can be delivered:

  • Closed captions are a separate text track that users can turn on or off. This is the most common approach on the web — using <track kind="captions"> or a player’s built-in caption toggle (the CC button). Closed captions give users control over whether they see the text.
  • Open captions are burned directly into the video frames. They are always visible and cannot be turned off. This can be useful when you cannot rely on the player supporting text tracks (e.g., social media videos, video you share in .PDF etc.), but it removes user choice and makes the captions impossible to resize or restyle.

For web accessibility, closed captions are preferred because they let users control the display, work with assistive technologies, and can be provided in multiple languages.

For further reading: Making Audio and Video Media Accessible (W3C WAI)

Add audio descriptions (AA)

Ask the question: Does the video have visual information that is needed to understand the content? (WCAG 1.2.5)

If your video shows key visuals (e.g., actions, diagrams, on-screen text) that aren’t described in the narration or dialogue, you must provide audio description. It describes the visual information needed to understand the content, including text displayed in the video.

The girl in a fur hat describes a video to a fish in a bowl: "Okay, I will describe it for you... A person is cleaning an aquarium"

The best way to handle description is often not to need it at all — integrate all visual information into the main audio. This is called “integrated description.”

For example, instead of a narrator saying “As you can see here…” while showing a chart, the narrator would say “This bar chart shows that 60% of users prefer dark mode.” — the visual information is already in the spoken words, so no separate audio description is needed.

How to provide descriptions

  • Integrate description into the main audio content (recommended)
  • OR provide a second audio track (kind="descriptions") or a separate video version with narration included
  • Add a way for users to select or toggle the audio description
<track src="descriptions_en.vtt" kind="descriptions" srclang="en" label="Audio Description">

Note that browsers don’t expose this track via controls, so you’ll need to build a custom toggle UI or provide a narrated version of the video.

Provide custom controls or ensure native controls are accessible

If you are using a ready-to-use video player library (e.g., Video.js, Plyr, or a platform like YouTube/Vimeo embeds), it likely already handles most of these concerns. This section applies when you build your own custom player on top of the native <video> element.

The HTML5 <video> element supports basic accessibility, including keyboard access to controls and support for captions/subtitles.

A fish in a bowl taps a keyboard to operate custom video controls with CC, play, skip, and volume buttons

However, it has limitations:

  • Inconsistent appearance across different browsers and operating systems
  • No custom focus styles
  • No transcript support or toggling of audio descriptions via the interface

Building accessible controls

If you need more control, replace the default controls with your own <button> elements and JavaScript:

For recommendations on building custom video players: Media Players (W3C WAI)

Provide a transcript (AAA)

It is best to provide captions and a separate transcript. (WCAG 1.2.3 / 1.2.8)

  • Captions enable people who are Deaf or hard of hearing to watch the video and read along at the same time
  • Transcripts provide access to people who are Deaf-blind and use braille, and are also used by people without disabilities

How to add a transcript

Include a full text transcript of the video content. Link to it near the video, display it in a toggleable section, or just include it in the page content below the video:

<button aria-expanded="false" onclick="toggleTranscript(this)">Read transcript</button>
<div id="transcript" hidden>
  <h2>Transcript</h2>
  <p>[Narrator]: Welcome to the tutorial...</p>
</div>

<script>
function toggleTranscript(btn) {
  const transcript = document.getElementById('transcript');
  const isHidden = transcript.hidden;
  transcript.hidden = !isHidden;
  btn.setAttribute('aria-expanded', isHidden);
  btn.textContent = isHidden ? 'Hide transcript' : 'Read transcript';
}
</script>

The aria-expanded attribute tells screen readers whether the transcript section is open or closed.

Alternatively, use the native <details> element — it handles expand/collapse and accessibility without any JavaScript:

<details>
  <summary>Read transcript</summary>
  <p>[Narrator]: Welcome to the tutorial...</p>
  <p>Today we'll learn how to make video content accessible.</p>
</details>

Here’s how it works — try clicking:

Read transcript

[Narrator]: Welcome to the tutorial. Today we’ll learn how to make video content accessible.

[Narrator]: First, let’s add captions to our video using a WebVTT file.

[background music]

Allow pause, stop, hide of auto-playing media (A)

  • Avoid autoplay whenever possible (WCAG 2.2.2)
  • If autoplay is required, provide controls to stop or pause the video

A startled fish and scared bunnies react to a loud autoplaying video ad — a stop or pause button is highlighted as a possible solution if autoplay is unfortunately required


FAQ: What if the video doesn’t need captions?

If your video does not need captions (because there is no substantive audio content) or does not need description (because there is no substantive visual content), it’s good to let users know. Otherwise, they might think you accidentally forgot to provide them.

A fish with glasses watches an aquarium video with no dialog, just background music — the caption track shows "[background lounge music]" to let viewers know no captions or description are needed

You can:

  • Provide a captions file with only the appropriate indication, such as [background music]
  • Provide the information in text with the video, such as: “Captions not needed: The only sound in this video is background music”

FAQ: Captions vs. subtitles

These terms are often used interchangeably, but they serve different purposes:

  • Captions are intended for viewers who cannot hear the audio. They include not just dialogue but also sound effects, music cues, and speaker identification — e.g., [door slams], [upbeat music], [Narrator]:.
  • Subtitles are intended for viewers who can hear but don’t understand the spoken language. They typically only include dialogue.

For accessibility, you need captions, not just subtitles.

FAQ: What do A, AA, AAA mean?

Each requirement in this article is marked with a WCAG conformance level:

  • Level A — the bare minimum. Without these, some users simply cannot access the content at all.
  • Level AA — the standard most organizations target. This is what most accessibility laws and policies require (e.g., EU’s EN 301 549, US Section 508).
  • Level AAA — the highest level. Not always feasible for all content, but provides the best experience.

See also: Practical accessibility testing