Live Shopping Streams and WCAG: What SC 1.2.4 Captions (Live) Actually Requires
Live shopping — a host walking through products on camera in real time while viewers buy without leaving the stream — has moved from a novelty into a routine sales channel. Instagram Live Shopping, TikTok Shop’s LIVE tab, YouTube Live Shopping, and Shopify’s own Live Selling features all put the same thing in front of a store’s customers: a live video feed with a running commentary and a “buy now” button next to it. It’s still video, but it isn’t the same accessibility problem as the product-demo clips already covered in our guide to accessible product videos — those rules are written for prerecorded content. A live stream falls under a different WCAG success criterion entirely, with its own requirements and its own failure modes.
Quick answer: WCAG SC 1.2.4 Captions (Live), Level AA, requires captions for the audio in any live broadcast — a live shopping stream’s host narration included. It’s a separate criterion from SC 1.2.2 Captions (Prerecorded), which only applies once that same video is saved and reposted as an on-demand replay. The criterion does not require captioning the back-and-forth chat/Q&A that runs alongside a stream — only the broadcast audio itself.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for live video content and how to meet it, not whether a specific implementation carries legal risk.
Live and prerecorded aren’t the same rule
It’s easy to assume “we already handle video captions” covers this, because most stores already caption their product-demo and unboxing videos. That assumption is wrong for a live stream specifically, because WCAG splits captioning into separate criteria depending on timing:
- SC 1.2.2 Captions (Prerecorded) — Level A — governs video that’s already finished and uploaded: a demo clip, an unboxing video, a size-guide walkthrough. There’s time to review and correct captions before anyone sees them.
- SC 1.2.4 Captions (Live) — Level AA — governs audio in a broadcast happening right now. There’s no review pass before the audience hears it; captions have to be generated and delivered in real time, as the host talks.
The Understanding doc’s own Intent section states the goal plainly: “to enable people who are deaf or hard of hearing to watch real-time presentations.” A live shopping host describing fit, fabric, or a flash-sale price verbally is exactly the audio this criterion is written for — if a deaf or hard-of-hearing shopper can’t follow along, they can’t make the same split-second buying decision as everyone else watching.
Once the stream ends, the relationship flips. A saved recording reposted as an on-demand replay stops being “live” the moment it’s no longer happening in real time — at that point it’s prerecorded content, and SC 1.2.2 (plus the audio-description and audio-only alternatives in our product-video guide) governs it instead, with the normal review-before-publish standard. Treat live and replay as two separate compliance checkpoints for the same footage, not one.
What the criterion doesn’t require
The Understanding doc carves out one explicit exception worth knowing before you over-scope this: it “is not intended to require that two-way multimedia calls between two or more individuals through web apps must be captioned regardless of the needs of users. Responsibility for providing captions would fall to the content providers (the callers) or the ‘host’ caller, and not the application.” In practice, for a live shopping stream, that means the criterion is about the host’s broadcast audio — not the scrolling text chat or voice-note Q&A viewers send in. Text chat is already readable by anyone regardless of hearing, and the live two-way conversation carve-out applies to the interactive side of the experience. Don’t spend engineering time trying to caption the comment stream; focus the work on the one-way broadcast feed.
How real-time captioning actually gets done
Technique G9 — one of the sufficient techniques for this criterion — frames the requirement as an operational one, not a one-time setup: “Check that a procedure and policy are in place to ensure that captions are delivered in real-time.” That’s a meaningfully different ask than uploading a caption file once. Every single live stream needs its own captioning pipeline running while it airs. In practice that means one of:
- Human stenographer or CART (Communication Access Realtime Translation) services — the most accurate option, booked and connected per stream, a real recurring cost to weigh against stream frequency.
- Re-voicing speech-to-text — a human repeats the host’s words into speech-recognition software tuned for cleaner input than the original audio, catching mishearings before display.
- Automatic speech recognition (ASR) with no human in the loop — the lowest-friction option, and the riskiest for accuracy. Unlike a prerecorded video, there’s no chance to fix a misheard price before the viewer sees it — “forty-nine ninety-nine” displayed as “fourteen ninety-nine” is live and uncorrected at the exact moment it matters.
Whichever path a store picks, the criterion is asking for a standing policy — who’s responsible for captioning being live and running before the “Go Live” button gets pressed, every time, not just the first time.
Closed vs. open captions — and why it matters for embedded live-shopping widgets
WCAG recognizes two ways to deliver live captions, and the platform a store streams through decides which one is actually available:
- Closed captions (Technique G87) — captions exist as a track a viewer can toggle on or off, invisible unless the viewer turns them on. This requires the video player itself to have caption-toggle support built in.
- Open captions (Technique G93) — captions are burned directly into the video image, always visible to every viewer, with no player support required at all.
This isn’t academic for live shopping specifically: a lot of live-selling traffic runs through an embedded third-party widget (a live-commerce platform’s player dropped into a product page, or a native in-app experience inside Instagram/TikTok/YouTube) rather than a store’s own custom player. If that embedded player has no caption toggle, closed captions aren’t an option at all — open captions, generated by the same real-time pipeline and overlaid onto the outgoing feed before encoding, become the only way to meet this criterion there. Check what your specific streaming setup actually exposes before assuming either option is available.
Why this is a complete blind spot for automated scanning
axe-core’s own rule descriptions include exactly one caption-related rule, video-caption, tagged wcag122 — SC 1.2.2, prerecorded content only. It works by checking whether a <video> element on the page has a <track> element attached. There’s no equivalent rule for live content, and structurally couldn’t be one: by the time a scanner crawls a page, a stream that already happened is gone, and a stream happening right now usually isn’t a scannable <video> element on your own domain at all — it’s a live feed inside a third-party platform’s embed or app, outside the reach of a crawler pointed at your site. This is one of the clearest cases of a requirement no scanner can evaluate even in principle, not just one a given tool happens to miss. Verifying it means someone watching the live stream in real time with captions on, checking they’re present, roughly accurate, and not lagging the audio by more than a few seconds.
FAQ
Does this apply if we just do an Instagram or TikTok Live and don’t build our own player? Yes. SC 1.2.4 is about the audio content being captioned, not about who built the video player. If the platform you’re streaming through offers a native live-captioning toggle, turning it on and having a person watch the first few minutes to sanity-check the caption quality is the fastest path to meeting this. If it doesn’t, you’re responsible for sourcing captions another way — a connected CART/stenography service or an open-caption overlay in your streaming software — before you rely on that platform for live selling.
If we save the stream and post it as a replay, do we need to redo anything? Yes, but it’s a different job: once the stream is over, the recording is prerecorded content, and SC 1.2.2 applies instead of 1.2.4. Whatever captions ran live during the broadcast should be reviewed and corrected before the replay goes live as an on-demand video — the same accuracy standard any other prerecorded product video on the site needs, covered in full in our product-video accessibility guide.
Do we need to caption the comments/chat during the stream? No — the Understanding doc’s own two-way-communication exception means a live interactive chat or Q&A alongside the stream isn’t in scope for this criterion. Scrolling text chat is already visually readable regardless of hearing; the obligation here is specifically about the host’s spoken broadcast audio.
Manual review catches what a scan structurally can’t
A full accessibility audit from Quietramp includes the kind of manual, in-the-moment review that automated scanning can’t do by design — including checking whether a live-commerce setup actually has a working captioning pipeline, not just whether a page’s static markup looks correct. See a real sample report, or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.