Video Accessibility Requirements: Captions and Transcripts

Accessible media requires more than a captions toggle. People need alternatives for speech, meaningful sounds, and visual information, plus a player they can operate. The right deliverables depend on whether the media is live or prerecorded, whether it contains video, and which conformance level your project targets.

Inventory the media and its controls

List every media asset, including embedded demonstrations, podcasts, onboarding clips, live events, and third-party players. Record its purpose, publication status, languages, and owner. A prerecorded interview with little meaningful visual action needs different production work from a silent tutorial demonstrating an interface.

Use the contrast checker to evaluate player labels, control icons, and caption color combinations. Check caption text against its actual background; a solid or sufficiently opaque caption box is easier to evaluate than text placed directly over changing footage. The tool cannot judge timing, accuracy, or keyboard access.

Begin with the WAI media accessibility guidance and document the required alternatives before commissioning the recording. Production planning is cheaper than discovering after launch that essential actions were demonstrated silently. The accessible interface guide supplies the broader context for operable controls and understandable labels.

Choose alternatives that meet the actual requirement

For prerecorded audio-only content, WCAG 1.2.1 at Level A generally requires an alternative for time-based media, typically a transcript. For prerecorded video-only content, it generally requires either a time-based media alternative or an audio track presenting equivalent information. The criterion includes an exception for media that is itself a clearly labeled alternative for text.

Prerecorded synchronized media generally needs captions under 1.2.2 at Level A. Under 1.2.3 at Level A, provide audio description or an alternative for time-based media for the visual information. At Level AA, 1.2.5 requires audio description of prerecorded video content in synchronized media when that visual information is not already conveyed in the audio.

Consequently, a transcript alone does not replace required captions, and a descriptive transcript alone does not satisfy the AA audio-description requirement. If all relevant visual information is already communicated in the main soundtrack, additional description may be unnecessary. Evaluate the content rather than automatically commissioning an empty description track.

Live synchronized media requires captions at Level AA under 1.2.4. Do not confuse a live event with its archived recording: the recording becomes prerecorded content and needs a separate publication review. A vendor's real-time caption feature is a starting point, not evidence that the resulting captions are accurate.

Consult the WCAG time-based media requirements when classifying edge cases, including media alternatives for existing text. Record the applicable criterion alongside each deliverable so future editors understand why it exists.

Produce captions people can follow

Good captions include dialogue, relevant speaker identification, and meaningful non-speech audio. “[Alarm sounds]” can be essential when the alarm explains someone's reaction. Background music need not receive a detailed description unless its character contributes to understanding.

Treat automatic captions as a draft. Review names, product terminology, numbers, negation, and punctuation against the audio. A missing “not” can reverse an instruction. Have a reviewer watch the complete asset with sound muted rather than proofreading the text alone.

Synchronize cues with speech and allow enough reading time. Avoid breaking a short phrase across multiple rapid cues. Keep captions clear of lower-third titles and demonstrations, and check the player at narrow widths where a two-line cue may wrap further. Editorial conventions vary, so establish a house style rather than presenting arbitrary line lengths as WCAG thresholds.

A basic native implementation can attach a WebVTT track:

<video controls preload="metadata" poster="demo-poster.jpg">
<source src="demo.mp4" type="video/mp4">
<track kind="captions" src="demo-en.vtt"
       srclang="en" label="English" default>
</video>
<p><a href="demo-transcript.html">Read the demo transcript</a></p>

WEBVTT

00:00:01.000 --> 00:00:04.500
[Alex] Select Export to download the report.

00:00:05.000 --> 00:00:07.500
[Notification chimes]
Your report is ready.

The example transcript filename represents a resource you must publish, not something browsers generate. Confirm track delivery, correct server configuration, and cross-origin permissions when assets use a separate host. MDN's track documentation explains the track element and its attributes.

Write transcripts and describe essential visuals

A useful transcript has a meaningful title, speaker labels, and paragraphs or headings that follow the content. Include relevant sounds and link text where necessary. For long recordings, timestamps help readers locate the corresponding segment without forcing every sentence into caption-style fragments.

A descriptive transcript also explains important visual information: charts, demonstrated actions, displayed text, and scene changes that affect meaning. Write “The error summary lists two missing fields” instead of “An error appears.” Do not spend paragraphs describing decorative clothing while omitting the result of a button press.

For audio description, identify gaps in the soundtrack where essential visual information can be spoken. When recording a tutorial, integrate that information into the original narration: “Choose Export in the upper-right corner; a download confirmation appears.” This often creates a better experience than bolting on a separate description later.

If pauses are too short for essential description, plan an alternative described version or a player and production workflow that supports the necessary description. Publish alternatives together so users do not need to contact support to obtain them. Make the transcript easy to find beside the player, not hidden in unrelated documentation.

Test the player as a complete interaction

Start with native controls where practical, but test the browser and device combinations you support. Custom players must expose names, roles, states, and values for controls such as play, mute, volume, progress, captions, playback speed, and fullscreen.

Use only the keyboard to reach every control, activate it, adjust sliders, open menus, and leave the player. Confirm that focus remains visible and is restored sensibly when a settings menu closes. Avoid global single-letter shortcuts unless they meet the applicable shortcut requirements, such as being disableable, remappable, or active only on focus.

With a screen reader, verify that play state changes and caption settings are understandable. Do not announce playback time continuously; constant updates can overwhelm other speech. Check that opening fullscreen does not trap users and that returning to the page preserves a sensible position.

Finally, test captions on a small screen, zoom the page, and examine autoplay behavior. Avoid unsolicited playback; WCAG also has requirements for controlling audio that starts automatically. Keep findings in your accessibility review backlog with the asset version, browser, assistive technology, and reproduction steps. Recheck alternatives whenever the edit changes, since even a short introduction can shift every caption cue.

Key takeaways

• Match alternatives to media type and the targeted WCAG level.
• Captions, transcripts, and audio description serve distinct purposes.
• Review automated captions against the complete recording.
• Describe meaningful visual information, not merely scenery.
• Test player controls with keyboard and assistive technology.
• Update media alternatives whenever the underlying asset changes.