WCAG 1.2.9 Audio-only (Live): How to Make Live Audio Accessible

WCAG 1.2.9 applies to live audio-only content and says you must provide an accessible alternative so people who are deaf or hard of hearing can get the same information. This article shows how to make live audio accessible, with practical methods, a step-by-step plan for small teams, testing tips and a short compliance checklist.

What WCAG 1.2.9 Audio-only (Live) covers

The success criterion focuses on live audio that carries unique information. If a live stream, webcast, broadcast or phone conference delivers spoken content without a visual equivalent, you need a real-time text alternative. That may be captions, a live transcript or another method that gives the same information at the same time.

Does WCAG 1.2.9 apply to your content?

Ask these questions to check scope:

• Is the event live or happening in real time?
• Is the content audio-only, with no visual text that conveys the same information?
• Does the audio carry important information people need to understand the event?

If the answer is yes to all three, plan an accessible alternative for the live stream.

What counts as an acceptable live alternative

There are three common approaches that meet the need for a live text alternative. Choose the one that fits the event, audience and budget.

1. Human real-time captioning (CART or stenographer)

Certified real-time writers produce near-instant captions. Accuracy is high for planned events. This works well for conferences, broadcasts and lectures. It requires booking a trained provider and feeding their captions into your player or platform.

2. Automatic speech recognition (ASR) with human monitoring

ASR systems provide fast captions at lower cost. Add a human editor to correct major errors and monitor speaker changes. This hybrid reduces mistakes that pure ASR makes on names, jargon and overlapping talk.

3. Real-time text feed or chat-based transcript

For smaller events, a live text feed works. A designated transcriber types a running transcript into a web page or chat window. Make sure the feed is updated continuously and is labelled clearly for users relying on assistive technology.

Step-by-step for a small team (podcasts, panels, radio)

1. Plan the delivery. Decide whether to use captions, a live transcript or both. Consider audience size and language needs.
2. Choose a provider. For higher accuracy hire a CART provider. For lower cost use ASR plus a human monitor. Test providers on your content type.
3. Design the user interface. If the audio is streamed on a web page, show a clear link labelled “Live captions” or “Live transcript”. Ensure the text is selectable and uses semantic HTML so screen readers can access it.
4. Integrate the captions or feed. Use WebVTT or a live caption API when possible. For chat feeds, provide an ARIA live region so screen readers announce updates appropriately.
5. Label speakers and events. Include brief speaker names, pauses and non-speech sounds that matter for meaning, such as applause or laughter.
6. Monitor quality during the event. Have someone watch captions for major errors and speaker misattribution. Fix problems quickly.
7. Publish a transcript after the event. Clean the live text, add timestamps and make it downloadable as HTML or text for people who need it later.

Practical setup examples

Live podcast stream

Send the audio to an ASR service. Pipe the ASR output to a moderator who corrects names. Display the corrected feed on the podcast web player as a live transcript. After the show, edit and publish a clean transcript.

Conference panel

Book CART for keynote sessions. Feed the captions into the event streaming player via WebVTT or an API. Provide a parallel chat-based transcript for breakout rooms where CART is not available.

Quality trade-offs and targets

Accessibility needs two things: text that accurately reflects content and text that appears close to the moment the audio is spoken. Higher accuracy usually means higher cost and slightly more latency. Pure ASR is fast but will mis-handle names, accents and technical terms. Human captioners are accurate but cost more and need scheduling.

When choosing, prioritise clarity of meaning over word-for-word perfection. Mark unclear passages with notes such as “inaudible” rather than leaving nothing.

Testing and verification

Use these checks before and during live events:

• Run dress rehearsals with the exact audio setup and captions enabled.
• Ask at least one deaf or hard of hearing participant to test the live feed and give feedback.
• Check the transcript for speaker labels and non-speech cues.
• Confirm the live text is reachable by screen readers. Use ARIA live regions or standard caption tracks supported by the player.

Common mistakes to avoid

• Relying solely on post-event transcripts. Live events need a concurrent alternative.
• Using ASR with no human review for complex or technical content.
• Hiding the live-caption switch behind more than one click or in a non-obvious place.
• Publishing autosave raw captions as the final transcript without editing.

Privacy and accessibility considerations

Inform participants if a third party will transcribe or caption the event. Get consent where required. For sensitive discussions, consider secure human captioning or encrypted ASR connections. Publish a clear accessibility statement that describes the live captioning method and where to find transcripts after the event.

Quick compliance checklist for WCAG 1.2.9

• Identify live audio-only content in your programme list.
• Select a live captioning or transcription method before the event.
• Ensure captions/feeds are available in the same time frame as the live audio.
• Label speakers and non-speech information in the live text.
• Test with assistive technologies and real users.
• Publish an edited transcript after the event and link it clearly.

Following these steps gives people who are deaf or hard of hearing the same access to live audio content. If you need a simple plan for a single show, start with ASR plus a human monitor and publish a cleaned transcript afterwards.