Video and audio accessibility for ecommerce: captions, transcripts and descriptions

Video is now standard on ecommerce product pages. Shoppable live events are growing. Background audio on hero sections is common. Each of these has accessibility requirements under WCAG. Most ecommerce stores ignore them entirely.

The deaf and hard-of-hearing community represents roughly 15% of the global population. Users with cognitive disabilities benefit from captions. Users in noisy environments or who prefer silent browsing turn off audio. Captions serve all of them. Beyond accessibility, captions are indexed by search engines, improving video SEO. There are no good reasons not to add them.

WCAG 1.2: the time-based media guidelines

WCAG groups media accessibility requirements under Guideline 1.2, which has eight success criteria spanning Levels A, AA and AAA. For ecommerce, the relevant ones are:

• 1.2.1 Audio-only and Video-only (Prerecorded), Level A: prerecorded audio-only content needs a text alternative. Prerecorded video-only content (no audio track) needs either a text alternative or an audio track.
• 1.2.2 Captions (Prerecorded), Level A: prerecorded video with audio needs captions.
• 1.2.3 Audio Description or Media Alternative (Prerecorded), Level A: prerecorded video needs an audio description or full text alternative.
• 1.2.4 Captions (Live), Level AA: live video with audio needs captions.
• 1.2.5 Audio Description (Prerecorded), Level AA: prerecorded video needs an audio description.

The Level A requirements are the floor. Every ecommerce site claiming any level of WCAG conformance must meet them. Level AA adds the live captions requirement and upgrades audio description from optional to required.

Product video captions: what is required

A product demo video showing someone using a product, with a voiceover explaining features, is prerecorded video with audio. WCAG 1.2.2 requires captions at Level A. This is not optional at any level of conformance.

Captions must be synchronized with the audio. A text transcript at the bottom of the page does not satisfy 1.2.2. The captions must appear on or with the video, timed to match the speech.

Captions must identify who is speaking when multiple speakers are present. They must include non-speech audio information that is relevant to content comprehension: "[upbeat music]", "[crash sound]", "[crowd cheering]". Auto-generated captions that YouTube or Vimeo produce are often accurate enough for simple product narration but should be reviewed before publishing.

Auto-captions common failure modes: misrecognizing product names and brand terms, garbling technical specifications, dropping punctuation that changes meaning, misidentifying speakers. Always review and correct auto-generated captions before publishing to your site.

Audio descriptions for product demos

Audio descriptions narrate visual information that is not conveyed in the dialogue or audio track. They fill the gaps: describing on-screen text, transitions, and visual content that a blind user would miss.

For a typical product demo video where the voiceover says "simply press the button to start," audio description would add "the red power button is on the left side of the device." Without this, a blind user hears a vague instruction but has no idea where the button is.

Implementing audio descriptions has two options. Extended audio description pauses the video to allow the description to be spoken, then resumes. This works for content where the original audio does not have natural pauses. A separate audio description track that users can toggle is the more common production approach.

For WCAG 1.2.3 (Level A), you can satisfy the requirement with a full text alternative instead of audio description. This is a text document that describes all visual content in the video as it occurs. For most ecommerce product videos, a well-written product description combined with a structured text alternative satisfies 1.2.3 with less production overhead than a full audio description track.

At Level AA (1.2.5), a text alternative is no longer sufficient for videos where the visual content conveys information not in the audio. The audio description track is required.

Transcript requirements for audio content

WCAG 1.2.1 requires a text alternative for audio-only prerecorded content. Podcast episodes, recorded Q&As, audio product reviews: all of these need a transcript.

The transcript must be a text version of the audio content. For a podcast episode, this means a full verbatim or near-verbatim transcript of the conversation, with speaker identification. For a voice-only product review, it means a written version of what was said.

Transcripts serve users who are deaf or hard of hearing, users who prefer to skim content, non-native speakers who find text easier to process, and search engines. A study by 3Play Media found that adding transcripts to audio content increased SEO traffic to those pages by an average of 15%.

Live stream accessibility for shoppable events

Shoppable live streams have grown significantly in North America following the model established in East Asian markets. A brand hosts a live video event where viewers can purchase products shown in real time. These are live video with audio, and they fall under WCAG 1.2.4 (Level AA).

Live captions require real-time transcription. The options are: automatic speech recognition (ASR) services integrated into the streaming platform, human CART (Communication Access Real-time Translation) captioners, or hybrid systems where ASR produces a draft and a human corrects it.

Automatic captions for live streams have a typical lag of 2-5 seconds. CART captioners can produce captions with less than 1 second lag at 98%+ accuracy but cost $100-200 per hour. For high-stakes live shopping events, CART is worth the cost. For regular livestreams, ASR is acceptable if accuracy is monitored.

Beyond captions, live shopping events should consider: sign language interpretation (not required by WCAG but increasingly expected for major brands), live transcript availability for viewers who prefer text, and ensuring the interactive "add to cart" elements used during the stream are keyboard accessible.

Autoplay: what WCAG requires

WCAG 1.4.2 states that if any audio plays automatically for more than 3 seconds, the user must have a mechanism to pause or stop it, or a way to control the audio volume independently of the system volume. This is Level A.

Hero section videos with background music are a common failure. If the video starts playing with audio when the page loads, users must be able to stop it. A mute button or a pause button satisfies this. But many implementations have the button in a location that keyboard users cannot reach before the audio begins.

Silent autoplay videos (muted by default) do not trigger 1.4.2. But they may trigger 2.2.2 (Pause, Stop, Hide) if they contain moving content that distracts users. Users with cognitive disabilities, epilepsy or vestibular disorders may be harmed by looping background video. WCAG 2.2.2 at Level A requires that automatically moving content that lasts more than 5 seconds can be paused, stopped or hidden.

The practical rule: all autoplaying media needs a visible, keyboard-accessible stop/pause control. Videos with audio need a mute or volume control. Putting these controls inside the video player UI is fine if the player itself is keyboard-accessible.

Media player keyboard controls

Custom video players built with JavaScript and CSS frequently have keyboard accessibility failures. The play/pause button may only respond to mouse clicks. Volume sliders may not be keyboard-operable. The timeline scrubber may have no keyboard interaction at all.

WCAG requires that all functionality is operable via keyboard (2.1.1). For a video player, this means: play/pause toggles with Space or Enter, volume control with arrow keys, seek with left/right arrows on the timeline, fullscreen with a button that responds to Enter/Space, caption toggle with a button that responds to Enter/Space.

Native HTML5 video controls meet these requirements in all modern browsers. Custom player implementations need to be tested with keyboard-only navigation. The video element with native controls is the lowest-risk implementation.

If you use a video hosting platform (YouTube, Vimeo, Wistia), their embedded players are generally keyboard-accessible. YouTube's player has known issues with focus management in embedded mode. Wistia has strong accessibility support and allows caption file uploads in multiple formats. Vimeo supports caption uploads and has good keyboard accessibility.

Embedded social media video: TikTok and Instagram

Many ecommerce brands embed TikTok and Instagram Reels on their product pages as social proof. These embeds inherit the accessibility of the platform's embed code, which varies.

TikTok's embed provides a basic play/pause button but has limited keyboard accessibility and does not surface captions from TikTok's own caption system in the embedded view. Instagram's embed is similarly limited.

If you embed social video on product pages, you take on responsibility for its accessibility. Options: add a text transcript adjacent to the embed, link to the original post where the platform's native accessibility features are available, or avoid autoplay embeds in favor of static image links to the video.

For compliance purposes: social media embeds without captions or transcripts are failures of WCAG 1.2.2 and 1.2.1. The fact that they come from a third party does not transfer liability. See our screen reader testing guide for how to verify media accessibility manually.

Video SEO benefits of captions

Captions are not just an accessibility requirement. They are indexed text. Google can read caption files (SRT, VTT) uploaded to YouTube and Wistia. This means the spoken content of your product videos becomes searchable text.

A product demo video that verbally explains ten features the product page does not mention creates ten additional keyword opportunities. REI, which has invested heavily in video accessibility, reports that their captioned product videos rank for long-tail queries that their text product descriptions do not target.

SRT and WebVTT files can be uploaded to most video platforms. For self-hosted video using the HTML5 video element, the track element points to a WebVTT caption file: <track kind="captions" src="product-demo.vtt" srclang="en" label="English">. This is the correct implementation for captioning self-hosted video.

Background audio on homepages

Some ecommerce brands, particularly in fashion and lifestyle, add ambient audio to their homepages: music, ambient sound or narration. Under WCAG 1.4.2, if this audio plays automatically and lasts more than 3 seconds, a control is required.

Beyond the WCAG requirement, background audio on a website is generally considered poor practice for users with screen readers. Screen readers produce synthesized speech. Background audio interferes with the user's ability to hear the screen reader. Even low-volume background music makes screen reader output significantly harder to understand.

The recommendation: do not use background audio. If you must use it, start muted by default and provide an explicit unmute option. Never autoplay audio with volume above zero.

Frequently asked questions

Do product videos need captions for WCAG compliance?

Yes. WCAG 1.2.2 (Level A) requires captions for all prerecorded video content with audio. This includes product demonstration videos, brand story videos and customer testimonial videos on ecommerce sites.

Can product videos autoplay on ecommerce sites?

Video can autoplay only if it has no audio or the audio is muted by default with a visible unmute control. WCAG 1.4.2 requires audio control and WCAG 2.2.2 requires a pause mechanism for any moving content.

Do audio descriptions need to be provided for product videos?

WCAG 1.2.5 (Level AA) requires audio descriptions for prerecorded video when visual content conveys information not available in the audio track. For product demos showing features only visible on screen, audio descriptions are required.