What Makes a Video Player Accessible, and How to Test One

Why the player matters as much as the captions

A carefully reviewed caption file does nothing if the captions button cannot be reached without a mouse, or if a screen reader announces it as button with no name. The player sits between every accessibility feature you have prepared and the viewer who needs it.

Players come in three broad forms: the browser's built-in controls for the HTML video element, a custom or open-source player built on top of that element, and an embedded player from a hosting platform. Each can be accessible or not. The features below apply to all three; the differences between them are covered in the trade-offs section further down. For the wider set of checks a video needs before release, see the video accessibility checklist.

Keyboard operation and focus

Screen-reader users, people with tremors or limited hand movement, and people using switch devices often never touch a mouse, so every function must work from the keyboard.

• Every control is reachable with Tab and operable with Enter or Space: play and pause, seek, volume and mute, captions, settings, playback speed, fullscreen and any chapter or transcript buttons.
• Sliders such as seek and volume respond to arrow keys, ideally with larger jumps on Page Up and Page Down.
• Focus order follows the visual order of the controls, and focus does not jump to unexpected places when the player changes state.
• The focused control has a clearly visible outline. Custom players often remove the browser's default focus ring for appearance and forget to replace it.
• The keyboard never gets trapped. A viewer must be able to Tab out of the player, out of an embedded frame and out of fullscreen.
• Controls that auto-hide during playback reappear as soon as a key is pressed, and do not hide while one of them has focus.

Many players also offer single-key shortcuts, such as K or Space to pause, M to mute, F for fullscreen and C for captions. These help, but WCAG 2.1 and later are commonly read as asking that single-character shortcuts can be turned off or remapped, or only work while the player has focus, because speech-input users can trigger them by accident.

Screen-reader names, roles and states

A screen reader can only describe what the player's code exposes. Each control needs three things: an accessible name (Play, Mute, Captions), a role (button, slider, menu) and a current state.

• Toggle buttons announce their state, for example Captions, on, or Mute, pressed, rather than leaving the user to guess.
• The play button's name changes to Pause while the video is playing, or it reports a pressed state.
• The seek slider reports position in words a person can use, such as 2 minutes 30 seconds of 12 minutes, rather than a raw number.
• Menus for captions, speed and quality can be opened, navigated with arrow keys and closed with Escape, with the selected option announced.
• An embedded player inside an iframe has a meaningful title attribute, so the frame is not announced as just frame.

Captions: the toggle and the styling controls

• The captions button is visible in the main control bar, not hidden two levels deep in a settings menu.
• When several caption or subtitle tracks exist, each is listed with a clear human label, such as English captions or Español.
• Viewers can change caption size, text colour, background colour and opacity, and ideally font. Some people need much larger text; others need a solid background box to read over busy footage.
• The player respects system caption preferences where the platform provides them; major desktop and mobile operating systems have caption style settings, though how many players honour them varies.
• Captions render cleanly: line breaks preserved, accented and non-Latin characters correct, and the text kept clear of the control bar when controls appear.

In the browser, the HTML track element attaches timed text to a video and expects WebVTT files; SRT is not loaded natively by the track element, so players built on it either need VTT or convert SRT behind the scenes. Hosted platforms usually accept SRT and VTT uploads and handle display themselves. Whether captions are burned into the picture or delivered as a separate selectable track changes all of this, as explained in open versus closed captions.

Audio description support

Blind and low-vision viewers need a way to hear important visual information. Players handle this in a few ways, and support is far less consistent than for captions.

Alternate audio track

A second soundtrack with description mixed in, selectable like a language track. Clean for viewers, but not every player or platform offers track switching

Separate described version

A second video file with description built in, linked or switchable from the player. Works anywhere, at the cost of hosting two versions

Text description track

A WebVTT file of kind descriptions, intended to be voiced by a screen reader or synthetic speech. Most browsers do not voice these on their own, so it needs a player that implements it

Extended description

The player pauses the picture while a description plays, then resumes. Rare in off-the-shelf players

If a player offers none of these, the practical fallback is a described version linked prominently beside the standard one. What audio description provides, and how it differs from captions, is covered in audio description versus subtitles.

Transcript placement

A transcript should be reachable from where the video is, not on a separate page that viewers have to hunt for. Common patterns are a transcript directly below the player, a clearly labelled Show transcript button that expands it in place, or an interactive transcript that highlights the current line and lets viewers click a line to jump there.

Interactive transcripts must be accessible themselves: they should not steal focus or scroll the page while someone is reading, and each clickable line needs to work from the keyboard. A plain transcript beats a clever one that only works with a mouse. Layout options for the page are covered in publishing transcripts on your website.

Autoplay, motion and visual design

• Video does not start playing sound on page load. WCAG is commonly cited as asking for a pause or stop mechanism for audio that plays automatically for more than three seconds; the simplest way to comply is not to autoplay with sound.
• Muted background or hero videos have a visible pause control, since moving content that starts automatically and runs longer than five seconds is commonly expected to be pausable.
• Control icons and their focus outlines contrast clearly with the video behind them; the 3:1 ratio WCAG uses for interface components is a common benchmark.
• Buttons are large enough to hit reliably on touchscreens and by people with limited dexterity. WCAG 2.2 introduced a minimum target size criterion, commonly cited as 24 by 24 CSS pixels.
• The player works when the page is zoomed and on small screens, without controls overlapping or falling off the edge.

How to evaluate a player before choosing it

An hour of hands-on testing tells you more than any vendor feature list.

1. Put the mouse away and operate every control with the keyboard alone, including fullscreen and exiting fullscreen.
2. Turn on a screen reader, such as VoiceOver on macOS and iOS, NVDA on Windows or TalkBack on Android, and listen to what each control is called and how state changes are announced.
3. Load your own caption file, not the vendor's demo, and check characters, line breaks and timing on a real video.
4. Open the caption settings and try a large text size with a solid background.
5. Check how the player handles audio description: a second audio track, a described version or a description text track.
6. Zoom the page in, try a phone, and check that nothing overlaps.
7. Read the vendor's accessibility conformance report if one exists, often based on the VPAT template, then confirm its claims against your own results.

Trade-offs and common mistakes

Native browser controls are free and improving, but their accessibility differs between browsers and their caption styling options are limited. Custom players give full control over design and features, which also means full responsibility for keyboard handling, labels and focus management, and those are easy to break in a redesign. Hosted players save effort and usually accept caption uploads directly, but you inherit whatever accessibility the platform has and cannot fix it yourself.

• Removing focus outlines for appearance and never adding a visible replacement.
• Using generic div elements with click handlers as buttons, so they are invisible to keyboards and screen readers.
• Hiding the captions button inside a settings menu.
• Assuming a player that renders captions also supports description tracks.

How mydubly fits: caption files, not a player

mydubly produces caption and transcript files; it does not provide a video player, host videos or add an accessibility layer to an existing player. From a video or audio file chosen on your device, the subtitle generator gives you SRT and VTT files plus a plain transcript and a timestamped transcript. The VTT file can be attached to an HTML video element through a track element; the SRT suits platforms and desktop players that prefer it. Both are UTF-8, single-line cues, one per recognized segment, and the VTT generator page describes the format in more detail.

Because the files contain no positioning, the player's default caption placement applies, and because they contain recognized speech only, sound tags and speaker labels need to be added by a reviewer before the file is used as accessibility captions. Each job produces one subtitle track, in the spoken language or a chosen target language. mydubly does not produce audio description or description tracks.

Next step: test the player you already have

Before switching players, test the one on your site today with the seven steps above, one real video and its caption file. For each failure, decide whether configuration fixes it, a different player is needed, or a linked transcript and described version will cover it.