WCAG 1.2.9: Audio-only (Live)
A live audio stream with no text alternative is simply silence for someone who is Deaf or hard of hearing. This AAA criterion requires that live audio-only content comes with equivalent live text — real-time captions from a trained captioner, or the script when the broadcast is scripted.
The success criterion, in full
An alternative for time-based media that presents equivalent information for live audio-only content is provided.
“Equivalent” is the operative word: the text must carry the information in the audio — the speech, who is speaking, and meaningful sounds — closely enough in time that a reader can follow, and take part in, the live event.
AAA context: the live corner of Guideline 1.2
Guideline 1.2 divides media by two axes: prerecorded vs. live, and audio/video composition. Prerecorded audio-only is handled at Level A by 1.2.1 (transcript). Live synchronized media — video with audio — gets captions at Level AA under 1.2.4. That leaves live audio-only content, which only this AAA criterion covers. At Level AA, a live radio-style stream technically has no WCAG requirement at all; 1.2.9 closes that gap.
Note the boundary: once your live audio event has any video component, it is no longer “audio-only” and 1.2.4 (AA) applies instead. And once the recording is published afterwards, it becomes prerecorded audio-only content and 1.2.1 requires a transcript.
Who this helps
People who are Deaf
Live text is the only way to participate in an audio-only event in real time — to follow the discussion and contribute to Q&A while it is still open.
People who are hard of hearing
Even with amplification, live speech over a compressed web stream can be hard to make out. Captions provide a reliable parallel channel.
People in sound-hostile environments
Listeners in loud spaces, quiet offices, or on failing connections can follow the text stream when the audio is unusable.
Non-native speakers
Reading along with live speech significantly improves comprehension of fast or accented speech for many second-language users.
Ways to conform
- CART / real-time captioning: a trained human captioner listens to the stream and produces live text, delivered in a caption viewer or embedded text stream alongside the audio. This is the reference technique.
- Scripted broadcasts: when the audio follows a prepared script (a recorded-style announcement read live, an audio drama, a formal statement), providing that script to users during the broadcast conforms.
- Verified speech-to-text: automatic recognition only where its accuracy for this speaker and material has been verified — accuracy, speaker identification, and meaningful sounds still need to reach the reader.
✓ Passes
- An audio-only all-hands stream with a CART captioner and a live caption pane next to the player.
- A live reading of a prepared statement with the full script linked from the stream page.
- An audio webinar embedding a StreamText-style live text feed synchronized within seconds.
✗ Fails
- A live audio stream with no text channel of any kind.
- “Transcript available next week” as the only alternative for the live event.
- Unchecked auto-captions that garble names, numbers, and technical terms into noise.
Implementation patterns
1. Audio stream with an adjacent live caption region
Render the captioner’s output into a live region next to the player. Keep the region polite so it does not interrupt screen reader users mid-sentence, and let users pause the visual scroll.
<h2>Quarterly briefing — live</h2>
<audio controls src="https://stream.example.com/briefing"></audio>
<section aria-label="Live captions">
<h3>Live captions</h3>
<div id="captions" role="log" aria-live="polite"
class="caption-pane" tabindex="0"></div>
</section>
<script>
// Captions arrive from the CART provider over a WebSocket
const pane = document.getElementById("captions");
const ws = new WebSocket("wss://cart.example.com/session/1234");
ws.addEventListener("message", (event) => {
const line = document.createElement("p");
line.textContent = event.data; // e.g. "MAYA: Welcome, everyone."
pane.append(line);
pane.scrollTop = pane.scrollHeight;
});
</script>2. Scripted broadcast: publish the script with the stream
<audio controls src="https://stream.example.com/statement"></audio>
<p>
This broadcast is read from a prepared statement.
<a href="/statements/2026-07-09-remarks">
Read the full script of these remarks
</a>
</p>3. Caption-pane CSS that stays readable
Live text is read under time pressure — give it generous size, spacing, and contrast (see 1.4.6 Contrast (Enhanced)).
.caption-pane {
max-height: 14rem;
overflow-y: auto;
font-size: 1.125rem;
line-height: 1.6;
color: #f8fafc; /* ~17:1 on the dark background */
background: #0f172a;
padding: 1rem;
border-radius: 0.5rem;
}How to test for 1.2.9
- 1
Identify live audio-only content
List every real-time, sound-only experience: audio streams, audio webinars, audio conference bridges surfaced on the web. Live video events belong to 1.2.4 instead.
- 2
Confirm a live text alternative is announced and reachable
From the stream page, a user should find the caption pane, caption viewer link, or script link before or at the start of the event — not by asking support.
- 3
Join the event and compare audio to text
Listen while reading. Speech should be captured accurately, speakers identified, and meaningful sounds noted. Sample sections with names, numbers, and jargon — that is where quality collapses.
- 4
Measure the lag
The text should trail speech by seconds, not minutes. Check that a caption reader could still act on time-sensitive moments, such as a Q&A window or instructions.
- 5
For scripted broadcasts, diff the script against reality
If the script is the alternative, verify the broadcast actually follows it. Ad-libbed content that departs from the script is uncaptioned content.
Common failures
- Streaming live audio with no text alternative at all — the default state of most audio streams.
- Offering only a post-event transcript as the answer for the live experience.
- Relying on unverified automatic captions for content full of names, figures, or technical vocabulary.
- Captions delivered so late that Q&A or other time-sensitive participation has closed by the time users read them.
- No speaker identification in a multi-speaker discussion, leaving the text an unattributed wall of words.
- A caption viewer that itself is inaccessible — unreachable by keyboard, tiny low-contrast text, or a separate window nobody is told about.
Frequently asked questions
What does WCAG 1.2.9 Audio-only (Live) require?
It requires an alternative for time-based media that presents equivalent information for live audio-only content. In practice that means live text: real-time captions produced by a trained human captioner (often called CART — Communication Access Real-time Translation), or, when the broadcast follows a prepared script, the script itself made available to users. It is a Level AAA success criterion introduced in WCAG 2.0 and unchanged in WCAG 2.2.
What counts as live audio-only content?
Any real-time content that is sound with no video: live radio-style web streams, audio-only webinars or conference calls, live podcast recordings streamed to listeners, audio press briefings, and similar broadcasts. If the live content includes video (a webcast with a camera feed), it is synchronized media and falls under 1.2.4 Captions (Live) at Level AA instead.
Are automatic speech-to-text captions good enough for 1.2.9?
Usually not on their own. The Understanding document notes that automatic speech recognition can degrade badly with crosstalk, accents, background noise, and specialist vocabulary, so WCAG points to a human captioner using CART for reliable results. Automatic captions may be acceptable when they are demonstrably accurate for the material — for example, a single clear speaker with a good microphone — but for AAA conformance you should not assume they are; verify accuracy or use a professional service.
Can I just publish a transcript after the broadcast ends?
A post-hoc transcript is valuable — once the stream is archived it becomes prerecorded content and 1.2.1 applies — but it does not satisfy 1.2.9 for the live experience. The point of this criterion is equivalent access while the broadcast is happening, so Deaf and hard-of-hearing users can participate in real time. The exception is scripted content: if the broadcast reads from a prepared script, providing that script during the broadcast conforms.
How much delay is acceptable for the live text?
WCAG does not fix a number, but the alternative must be usable as the event unfolds. Professional CART typically runs only a few seconds behind speech, which preserves the ability to follow along and to participate in any live interaction such as Q&A. The longer the lag, the less 'equivalent' the alternative becomes — if questions close before the text of the discussion has arrived, the user did not have equivalent access.
Is 1.2.9 required by accessibility laws?
Rarely, because most regulations reference WCAG Level AA and this criterion is AAA. However, live captioning obligations for events do exist in other legal contexts (for example effective-communication requirements under the ADA for public events), and many organizations provide CART for all-hands meetings and public webinars as standard practice. For pure legal WCAG conformance at AA, live audio-only content is not covered; 1.2.9 is the AAA enhancement that covers it.
Related Success Criteria
Provide alternatives for prerecorded audio-only and video-only content.
Captions are provided for all prerecorded audio content in synchronized media.
Audio description or full text alternative is provided for prerecorded video content.
Captions are provided for all live audio content in synchronized media.
Audio description is provided for all prerecorded video content.