Videos with subtitles used to be rare. Today, they're the bare minimum viewers expect. Subtitles help the deaf and hard of hearing, people watching in a foreign language, anyone on a noisy subway or in a quiet office—and, as it turns out, practically anyone scrolling through their feed without sound.
But accessible video isn't just about subtitles. Players need to be keyboard- and screen-reader-friendly. Some viewers require a text transcript or audio description. And if you're embedding a video on a website, the embed must support all of these features.
This guide covers the practical aspects of accessible video hosting: what to publish with each video, what to check in the player, and how to test the results. It's not legal advice—requirements vary by country and industry—but it covers the basics expected by accessibility standards like WCAG.
Subtitles and Captions: What's the Difference
The two terms are often used interchangeably, but there's a useful distinction between them:
| Captions | Subtitles | |
|---|---|---|
| Intended for | Viewers who can't hear the audio | Viewers who can hear but don't understand the language |
| Includes | Dialogue, speaker names, significant sounds ("[door slams]", "[music]") | Dialogue only, usually translated |
| Language | Usually the same as the audio | Usually a different language |
In practice, most teams publish captions in the original language and subtitles in additional languages. Most players and file formats handle them identically. Some allow you to mark a track as "captions" so the viewer knows it includes sound descriptions.
Outside North America, the distinction is less strict—"subtitles" is often used for both. The key point: captions for deaf and hard-of-hearing viewers should describe not only speech but also meaningful sounds.
Subtitle File Formats: SRT and WebVTT
Two text formats cover virtually all needs:
SRT is the simplest and most common format. Numbered blocks with start and end times. Exported from most editing programs and transcription services. Looks like this:
1
00:00:04,000 --> 00:00:07,500
Welcome to the interview. Today we're talking about video accessibility.
WebVTT (.vtt) is a web standard for HTML5 players. Similar to SRT, but with additional features: styling, positioning, and speaker labels. It looks like this:
WEBVTT
00:00:04.000 --> 00:00:07.500
Welcome to the interview. Today we're talking about video accessibility.
Most editing tools and transcription services export both formats. A good video hosting service accepts both and automatically converts SRT to WebVTT for playback.
How to Create Good Subtitles
Automatic Subtitles: The Beginning, Not the End
Automatic transcription services (Whisper, Google Speech-to-Text, Otter.ai, Descript) are a good starting point. But they are not a finished product. Common issues:
- Proper names. "Siobhan" can become "Shivon" or "shiv on." The names of brands, products, and people should be verified manually.
- Numbers and abbreviations. "ISO 27001" can become "ISO 27,001" or "I so 27001."
- Technical terms. The jargon specific to your industry is what the machine knows the least.
- Punctuation. Automatic subtitles often ignore commas and periods, turning the text into a stream of consciousness.
Rule: the machine drafts, the human subtitles.
Principles of Good Subtitles
Accuracy First. Every name, number, and term must be correct. A viewer who relies on subtitles cannot double-check the audio.
Readable Timing. Each subtitle block should remain on screen long enough to be read—approximately one or two lines per few seconds. If the subtitles flash by faster than the viewer can read, they are useless.
Speaker Identification. When there are multiple speakers in a video and it's not clear who is speaking, provide their name: "Maria: We started the project in March."
Description of Significant Sounds. Not every background noise, but sounds important for understanding: [applause], [phone ringing], [silence]. For a viewer who can't hear the audio, the lack of sound description is a loss of context.
Short Lines. Subtitles should not obscure the image. A maximum of two lines, each no longer than 42 characters, is the standard recommendation for television and works well on the web.
Text Transcripts
A transcript is the full text of a video's audio, published next to the player or available for download. Transcripts help:
- People who can't watch the video at all — for technical, physical, or situational reasons
- Screen reader users — the video player isn't always fully accessible, but the transcript is always accessible
- Those who want to find a specific moment — text-based transcript search is faster than rewinding
- Those who want to quote — copying the text is easier than typing it out by ear
For interviews and lectures, transcripts are one of the most valuable accessibility features. And as a bonus, they provide search engines with readable text about the video's content, improving indexing.
Transcript Format
At a minimum, a text file with speaker separation and timestamps for navigation. Ideally, an interactive transcript would be located next to the player, where clicking on a line would skip the video to the corresponding point.
Player Requirements: Keyboard, Focus, and Screen Reader
The player must be accessible without a mouse. This is critical for people with motor impairments, but is also useful for anyone who prefers a keyboard.
Player Accessibility Checklist
Tab Navigation. Each control—play, pause, volume, subtitles, fullscreen, and quality—should be accessible by pressing Tab. If focus jumps over the subtitle button, it is unavailable to a keyboard user.
Hotkeys. Standard expectations: Space or K for play/pause, left and right arrow keys for rewinding, up and down arrow keys for volume, F for fullscreen, and C for subtitles.
Visible focus. When the user tabs between elements, the current element should be visually highlighted—by an outline, highlighting, or some other means. If the focus is invisible, the user won't know which button they are on.
Text labels for screen readers. Each button should have a text description that the screen reader will read: "Play," "Enable subtitles," "Fullscreen." If the button is simply an icon without an aria-label, the screen reader will say "button" without explanation.
Remembering subtitle selection. If the viewer has enabled subtitles, they should remain enabled when moving to the next video. Forcing the user to enable subtitles every time is a poor user experience for those who depend on them.
Subtitle contrast and styling
Subtitles should be legible on any background. White text on a translucent dark background is a reliable standard. Small font, no background, and subtitles placed over lower thirds are common issues.
Recommendations:
- Font Size — at least 16px on desktop, scalable on mobile
- Background — semi-transparent dark (rgba(0, 0, 0, 0.75) or similar)
- Contrast — at least 4.5:1 according to WCAG AA
- Position — bottom of frame, but not over important visual elements (lower thirds, graphics)
Some players allow the viewer to customize the subtitle style — size, color, and background. This is the best option for accessibility because each viewer can adapt the display to their needs.
Audio Description
Viewers with visual impairments may not receive information conveyed only visually, such as on-screen text, actions, graphics, and demonstrations. Audio description provides a voiceover for this information.
Two practical approaches:
1. Narrate as you film. If the presenter says, "As you can see from this graph, sales have doubled," a blind viewer gets the information. If the presenter silently shows a graph, they don't. A simple rule: voice everything you show.
2. Prepare a version with audio description. For important videos, create a separate audio track or upload a separate video with added descriptions of the visual elements.
Audio description is the most complex accessibility element and isn't always mandatory. However, for educational content and public organizations, it may be a legal requirement.
Accessible Embeds
When you embed a video on your website, accessibility depends both on the player and how you embed it:
- Title attribute for iframes. Give the iframe a meaningful name:
title="Interview: Accessible Design at Company X". A screen reader will read it, and the user will understand that they are in a frame before they enter it. - Don't autoplay with sound. Autoplay with sound disrupts the experience for screen reader users—the unexpected audio stream competes with the screen reader's voice.
- Transcript next to the player. Place the transcript or a link to it directly below the embedded player.
- Check that subtitles and keyboard controls work in the embed. Some platforms provide full functionality in the native player but limit it in the embedded player.
Accessibility Testing Matrix
| Testing | How to test | Passed when |
|---|---|---|
| Subtitles present | Enable subtitles | Each spoken line has a subtitle |
| Subtitle accuracy | Watch without sound | Names and terms are correct |
| Keyboard controls | Disable mouse | All controls are accessible and functional |
| Focus visibility | Tab through the player | Focus is always visible |
| Screen reader cues | Use a screen reader | Buttons are clearly announced |
| Subtitle contrast | View on a bright background | Subtitles remain legible |
| Transcript | View below the player | Full text available |
| Mobile version | Test on a phone | Subtitles and controls work |
Complete this checklist for each video before publishing. Eight checks take five minutes. This is significantly less time than reviewing accessibility complaints after publication.
Legal Context (Not Legal Advice)
Video accessibility laws vary by country:
- US: Section 508 (for federal agencies), ADA (for public organizations and businesses). Large companies have been sued for not providing captions on public videos.
- EU: The European Accessibility Act (effective in 2025) requires accessibility for digital products and services.
- Canada: The Accessible Canada Act and provincial laws such as Ontario's AODA set accessibility requirements for organizations, including web content.
General principle: if your video is intended for a public audience, captions and keyboard accessibility are an expectation, not an optional feature. For internal videos, the requirements are more relaxed, but good practices are beneficial to everyone.
How to choose an accessible video hosting service
Look for a platform that:
- Accepts subtitle files (SRT and WebVTT) in multiple languages for each video
- Displays subtitles everywhere the video appears—on delivery pages, in embeds, and on shared video pages
- Uses a keyboard-accessible player with text labels
- Doesn't surround videos with ads and autoplay recommendations that distract screen reader and keyboard users
How subtitles work in VodSpot
In VodSpot, you upload subtitle files—SRT or WebVTT—for each video, in any number of languages. SRT is automatically converted to WebVTT. You can mark a track as captions (including sound descriptions) or subtitles and select the default track.
Viewers switch tracks using the subtitle button in the player. Subtitles appear on delivery pages, in embeds, and on shared video pages—wherever the video plays. The player supports keyboard controls and adaptive streaming, with no ads.
VodSpot does not automatically generate subtitles or create audio descriptions. Hosting alone doesn't make a website legally compliant—the content you publish does.
Frequently Asked Questions
What is accessible video hosting?
It's a video hosting service that supports subtitles and transcripts, uses a keyboard-accessible player with screen reader labels, and keeps subtitles wherever the video is displayed.
Which subtitle format should I use?
WebVTT is a web standard. SRT is the most common export format. A good hosting service accepts both.
Are automatic subtitles sufficient?
They are a good draft, but usually require editing: names, technical terms, and punctuation require manual review.
Are subtitles preserved in embeds?
They should. Check that the subtitle button works in the embedded player on your website.
Are subtitles required by law?
It depends on the jurisdiction and type of organization. For public content and organizations subject to accessibility laws, yes. For internal content, it's usually a recommendation, not a requirement.
Is audio description required?
For most business videos, no. For educational content and public organizations, it may be a legal requirement. A simple first step is to vocalize everything you show: "In this graph, we see a 40% increase" instead of just showing it.