Goal
Ensure people who are deaf or hard of hearing can access live audio-only broadcasts.
Success Criterion · WCAG 1.2.9
Audio-only (Live)
An alternative for time-based media that presents equivalent information for live audio-only content is provided.
Level AAAWCAG 2.0Perceivable1.2 · Time-based Media
Copy button ready
What to do
Provide real-time text alternatives for all live audio-only content.
Why it matters
Live audio events like radio broadcasts, podcasts, and audio announcements are inaccessible without real-time text.
Success criterion
What WCAG 1.2.9 requires
Summarized directly from the official Understanding document so teams can quote the requirement accurately.
An alternative for time-based media that presents equivalent information for live audio-only content is provided.
Intent
Why WCAG created this requirement
- Live audio-only content (without video) requires real-time text alternatives for deaf and hard of hearing users.
- This differs from captions for video (1.2.4) because there is no visual component—only audio.
- Real-time transcription allows users to follow live events as they happen, not after the fact.
- The text should include speaker identification and descriptions of meaningful non-speech sounds.
Benefits
Who gains when you pass
- Deaf and hard of hearing users can follow live audio broadcasts, radio shows, and podcasts in real-time.
- Users in environments where they cannot play audio can still access live audio content.
- Non-native speakers can read along with live audio to improve comprehension.
- The real-time transcript can be archived for later reference.
- Users with auditory processing disorders benefit from having text to supplement or replace audio.
Why it matters
User impact when this criterion fails
Summaries drawn from the Understanding document help you socialize impact statements with product stakeholders.
Without real-time text alternatives, deaf users are completely excluded from live audio events.
Hard of hearing users may miss important information in live audio broadcasts.
Users unable to play audio (quiet environments, no speakers) cannot access live audio content.
Time-sensitive live announcements become inaccessible to those who cannot hear them.
Overview
All live audio-only content must have a real-time text alternative that conveys the same information as the audio. This applies to live radio broadcasts, live podcast recordings, audio-only conference calls, audio announcements, and any other live audio content that does not include video. The text alternative must be provided in real-time as the audio is broadcast, allowing deaf and hard of hearing users to follow along with live events.
- The text alternative must be provided in real-time—not as a post-event transcript.
- Methods include live captioning services (CART), real-time transcription software, or human transcribers.
- Include speaker identification when multiple people are speaking.
- Describe meaningful sounds that are not speech (music, sound effects, applause).
- Some delay is acceptable due to the real-time nature, but it should be minimized.
Reference: All summaries and highlights originate from Understanding WCAG 1.2.9 and the W3C quick reference.
Fast facts
- Conformance level
- Level AAA
- WCAG version introduced
- WCAG 2.0
- Principle
- Perceivable
- Guideline
- 1.2 · Time-based Media
Examples
Make success tangible for teams
Share pass/fail snapshots to coach designers, engineers, QA, and content authors.
Live podcast
Pass
A live podcast recording displays real-time transcription on the website: "HOST: Welcome back to Tech Talk. Today we're discussing... GUEST: Thanks for having me..."
Fail
A live podcast has no text alternative during the live broadcast, only posting a transcript days later.
Audio announcement
Pass
A live audio emergency announcement is simultaneously displayed as scrolling text on the website and app.
Fail
Emergency audio announcements play with no text alternative, leaving deaf users unaware of critical information.
Radio broadcast
Pass
An online radio station provides a live transcript stream alongside the audio player, including [music playing] and [advertisement break] markers.
Fail
An internet radio station streams audio-only with no option for live text.
Evidence to keep
Document conformance decisions
Capture artifacts for VPATs, procurement reviews, and regression testing.
- Document the real-time transcription service or method used for each type of live audio.
- Keep records of transcription service agreements and contact information.
- Create a pre-event checklist for setting up live transcription.
- Document backup procedures for transcription failures.
- Archive transcripts after live events for future reference.
Official resources
Deep dives and supporting material
Keep these links handy when writing acceptance criteria or responding to audits.
Understanding 1.2.9
Official W3C interpretation, techniques, and intent for Audio-only (Live).
Quick Reference 1.2.9
Filterable list of sufficient techniques and failures.
Technique G151
Providing a link to a text transcript of a prepared statement or script if the script is followed.
Technique G150
Providing text based alternatives for live audio-only content.
CART Services Information
National Association of the Deaf resource on real-time captioning services.
Implementation checklist
Capture progress and blockers
- Identify all live audio-only content (radio broadcasts, live podcasts, audio announcements, conference calls).
- Arrange for real-time transcription services (CART, live transcription software, or trained transcribers).
- Set up a display mechanism for the live text (web page, app interface, separate window).
- Ensure transcription includes speaker identification and meaningful non-speech sounds.
- Test the setup before going live to verify text delivery works correctly.
- Have a backup plan if primary transcription method fails.
- Provide clear instructions for users on how to access the live text alternative.
Testing ideas
Prove conformance with evidence
- Verify real-time text alternatives are available when live audio begins.
- Check that text appears with minimal delay as audio is broadcast.
- Confirm speaker identification is provided when speakers change.
- Verify meaningful sounds are described in the text.
- Test that the text display is accessible to screen readers.
- Compare text accuracy against the audio content.
- Test on multiple devices and browsers to ensure compatibility.
Related success criteria
More from Time-based Media (1.2)
WCAG 1.2.1Audio-only and Video-only (Prerecorded)Level AWCAG 1.2.2Captions (Prerecorded)Level AWCAG 1.2.3Audio Description or Media Alternative (Prerecorded)Level AWCAG 1.2.4Captions (Live)Level AAWCAG 1.2.5Audio Description (Prerecorded)Level AAWCAG 1.2.6Sign Language (Prerecorded)Level AAAWCAG 1.2.7Extended Audio Description (Prerecorded)Level AAAWCAG 1.2.8Media Alternative (Prerecorded)Level AAA