WCAG 1.2.9 Audio-only (Live): The AAA Requirement That Isn't Optional

A live radio webcast starts streaming. Somewhere in the audience, a deaf user opens the page, finds no captions, and leaves. No error message. No fallback. Just exclusion, in real time.

That's the failure mode WCAG 1.2.9 Audio-only (Live) (opens in new window) was written to prevent. While its AAA conformance level leads some teams to quietly deprioritize it, that framing misses the point. AAA doesn't mean optional—it means the bar is high enough that not every organization can clear it. For those who broadcast live audio, the question isn't whether to meet it. It's whether they've thought seriously about how.

The Requirement

WCAG 1.2.9 (opens in new window) sits under Principle 1: Perceivable, Guideline 1.2 (Time-based Media), at Level AAA. The requirement is direct: provide a text alternative for live audio-only content.

What that looks like in practice matters a great deal. The W3C's Understanding document is specific about quality. A trained human operator using a specialized keyboard to produce near-real-time captions is the gold standard. The text should keep pace with the audio and adapt when speakers deviate from any prepared script. A transcript works only when the audio follows a set script closely enough that the transcript remains accurate—and even then, live captioning is preferred because it runs in parallel with the event as it unfolds.

Three sufficient techniques satisfy this criterion:

• G151 (opens in new window) — Providing a link to a text transcript for live audio that follows a script
• G150 (opens in new window) — Providing text alternatives for live audio-only content
• G157 (opens in new window) — Incorporating a live audio captioning service into web pages

G157—a live captioning service—is the technique that matches the intent of the criterion. G151 and G150 are available, but they carry constraints. A transcript that "differs markedly from what actually happens" doesn't satisfy this criterion. The W3C is clear on that.

Why Live Captions Matter for Real Access

Deaf and hard-of-hearing users represent a substantial portion of the population, and live audio content—radio webcasts, live conference streams, real-time briefings—is often where information is freshest and most consequential. A live press conference, an emergency broadcast, a real-time public hearing: these are exactly the moments when delayed access isn't equivalent access.

Users with auditory processing disorders also benefit from live captions. So do non-native speakers navigating fast-spoken content. So does anyone in an environment where audio isn't usable—a library, a crowded transit hub, a shared office.

The exclusion isn't subtle. There's no degraded experience to complain about. There's simply nothing there.

One boundary the W3C draws carefully: this criterion applies to broadcast-style audio, not to two-way calls between individuals through web apps. Responsibility for captioning a private call falls to the participants or the host, not the application platform. That's a meaningful scope limitation—but it doesn't reduce the obligation for organizations publishing live audio content to an audience.

How to Meet WCAG 1.2.9

For most teams, the honest answer is that G157 (opens in new window)—integrating a live captioning service—is the only technique that reliably satisfies the criterion's intent. Here's what that implementation path looks like:

Live CART (Communication Access Realtime Translation) services use trained stenographers to produce captions with minimal delay, typically 3–5 seconds. The output streams as text that can be embedded directly in a web page alongside the audio player. Vendors provide either a hosted display widget or a WebSocket/API feed that development teams can integrate into custom players.

Script-based content (pre-written speeches, structured webinars) may qualify for a synchronized transcript under G151—but only if the speaker follows the script closely. Any significant deviation invalidates the approach. Teams that choose this path need a quality assurance step: someone verifying post-event that the transcript matched what was actually said.

Automated speech recognition (ASR) is not listed as a sufficient technique, and the W3C's language about "untrained operators" is instructive here. Current ASR accuracy rates vary significantly by speaker, accent, and audio quality. For live broadcast where accuracy matters—and it always does—ASR alone doesn't meet the bar this criterion sets. It may serve as a supplement, but not a substitute.

Technique	Use Case	Key Constraint
G157 (opens in new window) — Live captioning service	Any live audio broadcast	Requires CART vendor coordination and integration
G151 (opens in new window) — Script-based transcript	Scripted speeches only	Transcript must match what was actually said
G150 (opens in new window) — Text alternatives	Supplemental text content	Must be equivalent, not just descriptive
ASR (automated)	Not sufficient alone	Accuracy too variable for compliance

Testing and Implementation

Automated testing is essentially useless for this criterion. No scanner can evaluate whether a live caption stream exists, whether it's accurate, or whether it's keeping pace with the audio. The research on automated testing limitations is relevant here: automated tools cap out at roughly 37% detection of accessibility barriers—and for time-based media at Level AAA, that number is effectively zero.

What teams actually need is a pre-production checklist for any live audio event:

1. Is this content live audio-only (no synchronized video)? If yes, 1.2.9 applies.
2. Does the content follow a fixed script? If yes, G151 may be viable—but verify post-event.
3. If not scripted, is a CART service contracted and tested before the event?
4. Is the caption output integrated into the player UI, not just a separate link?
5. Is there a fallback if the captioning service fails mid-broadcast?

The operational complexity here is real. CART services require advance scheduling, technical integration, and budget. Teams building live audio features into products need to design for captioning from the start—retrofitting it is significantly harder. This connects directly to the compliance implementation challenges that emerge when accessibility is treated as a post-launch concern rather than a design requirement.

Legal Context and Organizational Obligations

For organizations subject to Section 508 (opens in new window) or operating under Title II of the ADA (opens in new window), AAA criteria may carry weight beyond WCAG conformance claims—particularly in the context of program accessibility and effective communication requirements. That's a legal analysis question, not a WCAG question, but it's worth flagging to legal counsel before dismissing AAA requirements as aspirational.

Making CART a Standard Practice

Through an operational capacity lens, WCAG 1.2.9 is a procurement and workflow problem as much as a technical one. The code integration for a CART feed is straightforward—the harder work is vendor selection, contract timing, and building captioning into event production workflows before a live stream goes out. Teams that treat this as a last-minute add-on will consistently fail it.

The organizations that meet this criterion reliably are the ones who've made CART coordination a standard line item in their live event planning, not an accessibility exception. That's a process design choice, and it's entirely within reach for any team that decides to make it. The strongest argument for investing in live captioning infrastructure is that it serves multiple audiences simultaneously—deaf users, non-native speakers, noisy environments—while also producing a searchable transcript artifact. Framing CART integration as a content strategy investment, not just an accessibility cost, tends to move leadership faster than compliance arguments alone.