Video Captions and Transcripts for Business Websites

Captions decide who can use your video

Business sites lean on video more every year. Product demos, founder welcomes, testimonials, how to guides, webinar replays. Each one carries information that often exists nowhere else on the page.

For a visitor who is deaf or hard of hearing, an uncaptioned video is a blank spot where that information should be. The same is true for the much larger group watching with the sound off on a phone, in an office, or next to a sleeping child.

Captions and transcripts are how that content reaches everyone. They are also among the most commonly skipped accessibility tasks, because they feel like production work rather than web work.

What WCAG actually asks for

The media requirements are specific, and worth stating plainly.

Success Criterion 1.2.2 asks for captions on prerecorded video with audio. Success Criterion 1.2.1 asks for a text alternative for prerecorded audio only content, such as a transcript for a podcast episode. At the AA level, Success Criterion 1.2.4 extends captions to live video, and Success Criterion 1.2.5 asks for audio description of prerecorded video, which narrates important visual information the soundtrack alone does not convey.

For a typical business site, the practical reading is straightforward. Every published video gets captions. Every audio recording gets a transcript. Live streams need live captioning if you host them. And a video that shows essential information silently, like a screen demo with no narration, needs that information available in text.

Auto captions are a draft, not a deliverable

Automatic captioning has improved enough to be genuinely useful, and not enough to ship unreviewed.

Auto captions reliably stumble on the words that matter most on a business site. Your company name, product names, industry terms, prices, and phone numbers. They also tend to omit punctuation and speaker changes, which turns a two person interview into an unreadable wall.

The working pattern is to let the platform generate the first pass, then have a person correct it. For a five minute video this is usually under half an hour of editing. Upload the corrected file, or fix it in the platform caption editor, and the result is captions that say what the video says.

Burned in captions, baked into the pixels, are better than nothing but weaker than closed captions. Closed captions can be toggled, restyled by the visitor, and read by the platform, and the caption file gives search engines the spoken content as text.

Transcripts are the cheapest win in media accessibility

A transcript is a plain text version of everything said, placed on the page near the video or linked clearly from it.

It serves visitors who cannot hear the audio, visitors who cannot watch video at all, and visitors who simply prefer to scan. It serves deafblind visitors using braille displays, for whom captions inside a player are unreachable. And it puts the spoken content of the video into the page itself.

If captions exist, a transcript is nearly free. Export the caption file, strip the timestamps, add speaker names and paragraph breaks. Many teams publish the transcript as a collapsible section under the video, which keeps the page tidy without hiding the content from anyone.

The player matters as much as the file

Captions inside an inaccessible player still fail visitors.

The player controls need to work by keyboard. Play, pause, volume, and the caption toggle itself. Most major hosted players handle this reasonably well, which is a real argument for embedding from an established platform instead of hand rolling a player.

Autoplay deserves special caution. Success Criterion 1.4.2 asks for a way to pause or stop audio that starts automatically, because a soundtrack talking over a screen reader makes the whole page unusable. The safer default is no autoplay at all, or autoplay muted with visible controls.

A workflow a small team can sustain

Media accessibility fails most often as a process problem, not a knowledge problem. The fix is a short checklist attached to publishing.

Before any video goes live: captions generated, captions corrected by a person, transcript posted or linked, player checked by keyboard, no unmuted autoplay. Five lines. If a video cannot meet them yet, publish the transcript first and the video when the captions are ready.

For the existing library, work in order of traffic. Caption the videos on your highest traffic pages first, then work backward. An audit of the site will show which pages with media carry the most reach.

How to verify the fix

Open each page with media. Play the video with the sound off and confirm the captions carry the content. Tab through the player and confirm every control responds. Find the transcript without using a mouse.

Then re scan the page. Automated checks catch some media issues, like missing caption tracks on native video elements and autoplay problems, and a structured review covers what automation cannot judge, like caption accuracy.

A free scan takes about a minute and flags media and player issues it can detect on the page you care about most. The full audit report documents where media findings sit alongside the rest of the barriers on the site, mapped to the WCAG criteria involved.

No scan certifies legal compliance, and this article is not legal advice. What captioning and transcript work does is make your most persuasive content available to every visitor, and it supports remediation toward WCAG 2.1 and 2.2 AA in a way you can demonstrate. Our compliance guide covers where media fits in a full remediation plan.