This post is part of a series where we explain Web Content Accessibility Guidelines (WCAG), an internationally recognized standard for measuring website accessibility. For more posts in this series, visit our Web Accessibility WCAG 2 Knowledge Base.
Continuing our WordPress accessibility series on WCAG conformance, we now turn our attention to live audio content and how to make it accessible to users who are deaf or hard of hearing. Live audio experiences—such as webinars, podcasts streamed in real time, virtual events or board meeting livestreams, and live discussions—can present major accessibility barriers when no equivalent text alternative is provided.
That’s where WCAG Success Criterion 1.2.9: Audio-only (Live) Level AAA comes in.
When your WordPress site includes live audio streams or real-time spoken content, this criterion ensures that users who cannot hear the audio still have access to the information being shared. Whether you’re hosting live interviews, community events, training sessions, or live podcasts, providing an accessible alternative helps create a more inclusive experience for everyone.
In this article, we’ll explain what WCAG 1.2.9 requires, why live audio accessibility matters, common implementation challenges, and practical ways to support accessible live audio experiences in WordPress.
What is WCAG 1.2.9 Audio-only (Live) AAA?
WCAG Success Criterion 1.2.9 Audio-only (Live) (Level AAA) states:
An alternative for time-based media that presents equivalent information for live audio-only content is provided.
Web Content Accessibility Guidelines 1.2.9
In plain terms:
If you provide live audio-only content, you must also provide an equivalent alternative that allows users who cannot hear the audio to access the same information.
This typically means providing:
- Live text transcription (real-time captions or CART services).
- A live text feed.
- Another equivalent real-time communication method.
Unlike prerecorded media requirements, this criterion focuses specifically on live audio content happening in real time.
This means:
- The alternative must communicate the same meaningful content as the live audio.
- A transcript published after the event is not enough on its own.
- Users need access to equivalent information while the event is happening.
This is a Level AAA success criterion, so it may not apply to your website. However, if you’re striving for the highest level of conformance or want to make your content as accessible as possible, read on for guidance on how to meet WCAG 1.2.9 Audio-only (Live) in WordPress.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Why WCAG 1.2.9 Matters
Imagine your WordPress site hosts a live audio webinar discussing a topic of interest to your customers or constituents. Speakers might answer audience questions, give presentations, and share important updates in real time.
Without a live text alternative:
- Users who are deaf or hard of hearing cannot follow the discussion.
- Participants may miss important announcements or instructions.
- Real-time interaction becomes inaccessible.
WCAG 1.2.9 ensures that live audio experiences are not limited to users who can hear spoken content.
Providing live transcription or captioning allows users to:
- Follow discussions as they happen.
- Participate equally in live events.
- Access information without relying on audio.
This is especially important for educational content, public events, board meetings that must comply with open meeting laws, customer support sessions, and professional webinars hosted on WordPress websites or other platforms such as Zoom.
How to Meet This Success Criterion in WordPress
If your WordPress site includes live audio-only content, WCAG 1.2.9 requires you to provide an equivalent real-time alternative.
How to provide accessible live audio alternatives
Here are common ways to support accessibility for live audio content:
- Use live captioning or CART services: Communication Access Realtime Translation (CART) services provide human-generated real-time transcription for live events. These services can:
- Display live captions during streams.
- Provide highly accurate transcription.
- Support webinars, meetings, and live broadcasts.
- Provide an integrated live text feed: Some streaming platforms support built-in live captioning or synchronized text updates.
- Use automatic speech recognition cautiously: AI-generated live captions can help improve accessibility, but they may:
- Misinterpret speakers.
- Struggle with accents or technical terminology.
- Introduce delays or inaccuracies.
Human-reviewed captioning is generally more reliable for critical or professional content, and is our top recommendation for meeting this requirement.
Examples of Accessible Live Audio
A WordPress site hosts a live audio panel discussion about inclusive design.
A compliant implementation might include:
- A live embedded caption window beneath the audio player.
- Real-time CART transcription.
- Clearly labeled access instructions before the event begins.
Instead of relying solely on audio, users can follow the conversation through synchronized text as the event unfolds.
Plan for Accessibility Before Going Live
Accessibility for live audio is much easier when planned in advance.
You can:
- Schedule captioning or CART providers in advance.
- Share terminology or speaker names with transcription providers.
- Test streaming and caption integrations before the event.
- Provide clear instructions for accessing captions.
Planning ahead reduces technical issues and helps ensure a smoother experience for all participants.
Not sure how to budget for real-time captions? See this webinar, Practical Advice for Meeting Caption, Transcript, and Sign Language Requirements, presented by Amber Hinds, where she shared the actual cost that we pay for captioning our live meetups and webinars.
How to Implement Live Audio Accessibility in WordPress
There are several ways to provide accessible live audio experiences on your WordPress site:
Embed accessible streaming platforms
Many streaming services support live captions or third-party integrations. When choosing the platform you will use for live streaming, make sure it includes real-time captions, and, if you’re embedding the video or audio on your website, that the captions or transcript are embedded as well.
Examples include:
These platforms may support:
- Embedded live transcripts
- Automated captions
- CART integration
Include live transcription alongside audio
You can:
- Embed a real-time transcript feed from a third-party service.
- Display captions beneath the audio player in an iFrame or container that pulls captions in via an API.
- Link users to a live captioning page on a third-party website.
Ensure the link or feature is clearly labeled, such as:
- “Accessible live text feed”
- “Live captions”
- “Real-time transcript”
Ensure keyboard accessibility
Make sure:
- Users can easily locate accessibility features.
- Caption controls are keyboard accessible.
- Embedded players support screen readers.
WCAG 1.2.9 Exceptions
There are limited situations where this criterion may not apply:
- Content with no spoken or informational value: For example, ambient sound streams without essential communication.
- Prerecorded audio: This criterion applies specifically to live audio-only content. There is a different AA success criterion for pre-recorded audio, WCAG 1.2.2 Captions (Prerecorded).
- Purely decorative audio: Audio that conveys no meaningful information.
Testing WCAG 1.2.9 Compliance in WordPress
1. Identify live audio-only content
Review your site for:
- Live podcasts
- Audio webinars
- Live discussions
- Streaming radio or events
Ask:
“Can users access equivalent information without hearing the audio?”
2. Verify the availability of a live alternative
Check whether:
- Real-time captions are available.
- CART transcription is functioning.
- Users can access text alternatives during the event.
Remember:
A transcript posted afterward does not satisfy this criterion.
3. Test accessibility of the implementation
Ensure:
- Caption links are clearly labeled.
- Controls are keyboard accessible.
- Embedded tools work with screen readers.
4. Test with assistive technology
Use tools such as:
- NVDA
- JAWS
- VoiceOver
Verify that:
- Accessibility features are discoverable.
- Live text updates are accessible.
- Focus order is logical.
Take an online course to learn screen reader testing
If you want to learn more about how to use a screen reader for accessibility testing, check out our online courses. These courses include detailed instructions on how to use a screen reader, what keyboard shortcuts to know, recommended settings for testing, and good and bad examples of multiple different components, so you know what to listen for.
Start Making Your WordPress Site More Inclusive
WCAG 1.2.9 Audio-only (Live) helps ensure that live spoken content remains accessible to users who cannot hear audio in real time.
While it is a Level AAA requirement, and not always legally required, it represents an important step toward fully inclusive live experiences.
Start by identifying live audio content on your WordPress site and evaluating whether users can access equivalent information as events happen. Implement live captions, CART services, or real-time text alternatives wherever possible.
Accessibility tools can help improve your workflows, but truly accessible live audio requires preparation, testing, and thoughtful implementation. By supporting real-time alternatives, you help ensure that all users can participate equally in your live content experiences.
