WCAG 1.2.9: Audio-only (Live)

What This Rule Means

WCAG Success Criterion 1.2.9, Audio-only (Live), falls under Guideline 1.2 (Time-based Media) at Level AAA. It states: "An alternative for time-based media that presents equivalent information for live audio-only content is provided." In practical terms, this means that whenever your website or application streams or delivers live audio content — and that content carries no video component — users must be given a real-time text equivalent that faithfully conveys the same information.

A live audio-only presentation is any audio stream that is broadcast in real time without a synchronized video track. Common examples include live radio programmes embedded on a webpage, live audio commentary during a sporting event, live press conferences streamed in audio format, live earnings calls or investor briefings, and live audio podcasts or talk-show streams where no video feed accompanies the audio.

The text alternative required by this criterion must be equivalent — meaning it must capture not just spoken words but also relevant non-speech audio information such as crowd noise, alarms, sound effects, or music that carry informational value. A partial or delayed transcript does not satisfy this criterion; the alternative must be updated synchronously (or near-synchronously) with the live stream so that deaf and hard-of-hearing users can follow the content in real time.

Acceptable techniques for meeting this criterion include providing a live human stenographer producing real-time text (CART — Communication Access Realtime Translation), embedding synchronized live captions generated by a qualified captioning service, or displaying a live text feed that runs concurrently with the audio broadcast. Auto-generated captions produced by speech recognition software may also satisfy the criterion provided the accuracy is sufficiently high and the output is presented in near real time.

What counts as a pass: The page provides a visible, synchronous text alternative — clearly linked or displayed adjacent to the audio player — that presents equivalent information to the live audio stream as it unfolds. The alternative must be perceivable by users who cannot hear the audio.

What counts as a fail: No text alternative is offered at all; a text alternative is provided but significantly delayed (e.g., a transcript posted after the event); a text alternative covers only a portion of the audio (e.g., only the presenter's speech but not audience questions); or a text alternative exists but is not accessible to assistive technology users (e.g., it is rendered as a non-focusable canvas element or locked inside a Flash widget).

Official exceptions: WCAG does not carve out specific exceptions for 1.2.9 beyond the general principle that the requirement applies only to live audio-only content. Pre-recorded audio-only content is covered by the separate criterion 1.2.1. There is no exception for short audio clips or brief announcements — if content is live and audio-only, the criterion applies.

Why It Matters

Approximately 466 million people worldwide have disabling hearing loss, according to the World Health Organization, and this number is projected to rise to over 900 million by 2050. For these users, live audio-only content is entirely inaccessible without a text equivalent. Unlike pre-recorded content — where a transcript can be prepared in advance and attached after the fact — live audio presents a unique challenge because the information is time-sensitive and ephemeral. A user who is deaf cannot simply replay a live stream later and expect the same experience; by definition, live content loses its immediacy once the moment has passed.

Consider a concrete real-world scenario: a publicly listed company hosts a live earnings call streamed as audio-only on its investor relations page. Analysts, journalists, and retail investors who are deaf or hard of hearing cannot participate in — or even passively follow — the call without a real-time text feed. Important financial disclosures, guidance updates, and responses to analyst questions are communicated in real time, and any delay in receiving that information places these users at a significant informational disadvantage. In regulated industries, this can even raise questions of equitable access to public information.

Beyond deafness, this criterion benefits a wider population. Users with auditory processing disorders may hear audio but struggle to decode speech rapidly enough to follow a live stream; a synchronized text feed allows them to read at their own comprehension pace while the audio plays. Users in noise-sensitive environments — such as open offices, libraries, or public transport — who cannot play audio aloud benefit from a text alternative. Users for whom the broadcast language is a second language also find text alternatives easier to follow than fast-paced live speech.

From an SEO and content discoverability standpoint, a live text transcript or captions feed creates indexable text that search engines can crawl. Live events that generate real-time text are more likely to surface in search results and news aggregators, expanding audience reach well beyond the original broadcast window.

For organisations operating in regulated sectors — financial services, healthcare, government — providing equitable access to live audio information is increasingly an expectation rather than a courtesy. Failing to meet this criterion can expose organisations to complaints, reputational risk, and in some jurisdictions, legal liability.

Related Axe-core Rules

WCAG 1.2.9 requires manual testing; no automated axe-core rule can reliably detect whether a live audio-only stream has a synchronous text alternative. The reasons for this limitation are fundamental to the nature of the criterion:

• Why automation cannot catch this violation: Automated tools like axe-core operate on static DOM snapshots or page states at a single point in time. They can detect the presence of an <audio> element or a media player, but they cannot determine whether the associated content is live or pre-recorded, whether a visible text area on the page is genuinely updating in synchrony with an audio stream, whether the text content is semantically equivalent to the audio (covering all speech and non-speech audio information), or whether any linked external captioning service is actually active and accurate. All of these judgements require human review of the live broadcast itself.
• What a manual auditor must check: The auditor must access the page while the live audio stream is active, identify how (or whether) a text alternative is presented, confirm the text alternative updates in real time as the audio progresses, verify that the text covers all meaningful audio content including speaker identification, non-speech sounds, and transitions, and confirm that the text alternative is accessible to assistive technology — for example, that a live region using aria-live='polite' or aria-live='assertive' is announcing updates to screen reader users appropriately.
• Partial automation signals: While axe-core cannot flag a missing live text alternative directly, auditors should note that axe-core will flag related issues that compound the problem — for example, if a text transcript area exists but is hidden with display:none, or if a media player lacks accessible controls. These flags serve as useful starting points during a manual review.

How to Test

1. Automated scan as a baseline: Run axe DevTools or Lighthouse against the page hosting the live audio stream. Note any flagged issues with media elements, missing labels, or inaccessible controls. While neither tool will directly flag a missing live text alternative, they may surface related barriers — such as an audio player with no accessible name or a transcript container that is hidden from the accessibility tree. Document these findings and treat them as part of the overall accessibility assessment.
2. Identify the live audio content: While the live broadcast is active, confirm that the audio stream is live (not a recording) and that it carries no video track. Check the page source and network requests for clues — live streams typically use HLS (.m3u8), MPEG-DASH, or WebSocket-based delivery. Confirm the content is audio-only.
3. Check for a text alternative: Look for a visible text area, caption overlay, or clearly labelled transcript feed on the page or immediately linked from the page. The alternative must be prominently surfaced — not buried in a settings menu or available only upon request. If no text alternative is visible, the criterion fails immediately.
4. Verify synchrony: With the live text alternative visible, listen to the audio stream and read the text feed simultaneously. Confirm that text updates within a reasonable lag (typically no more than a few seconds for CART or professional captioning services). A text feed that updates every several minutes or only after the broadcast ends does not satisfy the criterion.
5. Verify equivalence: Confirm that the text alternative captures all meaningful audio content: spoken words, speaker identification where multiple voices are present, relevant non-speech audio (e.g., "[applause]", "[alarm sounds]", "[music playing]"), and any on-air announcements or interruptions.
6. Screen reader test — NVDA + Firefox: Open the page with NVDA active. Navigate to the live text region. If the region uses aria-live, NVDA should announce new text insertions automatically. If it is a scrolling text area, verify that focus can be placed on it and that the content is readable. Check that the audio player controls are also operable by keyboard.
7. Screen reader test — VoiceOver + Safari (macOS/iOS): Enable VoiceOver and navigate to the live text region. Confirm that VoiceOver reads out new text as it appears. On iOS, also verify the experience on mobile — live events are frequently accessed via mobile browsers.
8. Screen reader test — JAWS + Chrome: With JAWS active, navigate to the page and confirm that the live region announcements are functioning. JAWS handles aria-live='polite' and aria-live='assertive' differently; confirm the verbosity setting is appropriate for the type of content (a fast-moving captions feed may be better suited to assertive to avoid queuing delays).
9. Mobile and low-bandwidth test: If the site serves a mobile audience, test the live text alternative on a mid-range Android device over a throttled connection. Confirm the text feed remains synchronised and accessible even under constrained conditions.

How to Fix

Scenario 1: Live audio player with no text alternative — Incorrect

<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'>
    Your browser does not support the audio element.
  </audio>
</section>

Scenario 1: Live audio player with ARIA live region transcript — Correct

<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
  <h2>Live Broadcast</h2>
  <audio controls src='https://stream.example.com/live'
         aria-describedby='live-caption-feed'>
    Your browser does not support the audio element.
  </audio>
  <!-- aria-live='assertive' ensures screen readers announce new text immediately -->
  <!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
  <div id='live-caption-feed'
       role='region'
       aria-label='Live captions'
       aria-live='assertive'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text is injected here by the captioning service JavaScript -->
  </div>
</section>

Scenario 2: Transcript posted only after the event ends — Incorrect

<!-- Transcript link appears but only resolves after the broadcast -->
<div>
  <audio controls src='https://stream.example.com/press-conference'></audio>
  <p>A full transcript will be available after the press conference concludes.</p>
</div>

Scenario 2: Real-time CART feed linked alongside the player — Correct

<!-- Real-time CART captions are displayed inline during the live event -->
<div>
  <audio controls src='https://stream.example.com/press-conference'
         aria-describedby='cart-feed'></audio>
  <!-- The CART feed is an iframe served by a professional captioning provider -->
  <!-- The iframe must itself be accessible with an appropriate title -->
  <iframe
    id='cart-feed'
    src='https://cart-provider.example.com/feed/press-conference-2025'
    title='Real-time captions for live press conference'
    width='100%'
    height='200'>
  </iframe>
  <p>A full transcript will also be published after the event concludes.</p>
</div>

Scenario 3: Auto-generated captions hidden behind a settings toggle — Incorrect

<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'></audio>
  <button onclick='toggleSettings()'>Settings</button>
  <div id='settings-panel' hidden>
    <button onclick='enableCaptions()'>Enable Captions</button>
  </div>
</div>

Scenario 3: Captions enabled by default with a clear toggle — Correct

<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
  <audio controls src='https://stream.example.com/webinar'
         aria-describedby='webinar-captions'></audio>
  <!-- Default state is captions-on; aria-pressed reflects current state -->
  <button id='caption-toggle'
          aria-pressed='true'
          onclick='toggleCaptions(this)'>
    Live Captions: On
  </button>
  <div id='webinar-captions'
       role='region'
       aria-label='Live webinar captions'
       aria-live='polite'
       aria-atomic='false'
       tabindex='0'>
    <!-- Caption text injected here in real time -->
  </div>
</div>

Common Mistakes

• Publishing a post-event transcript and claiming it satisfies 1.2.9: A transcript posted hours or days after a live broadcast is not a real-time text alternative. WCAG 1.2.9 specifically requires that the alternative be available concurrently with the live audio, not retroactively.
• Using aria-live='polite' for a fast-moving captions feed: Polite live regions wait for the user to finish interacting before announcing new content. For rapidly updating captions, this causes screen reader users to miss announcements. Use aria-live='assertive' for live caption streams where each update is time-critical.
• Injecting the entire caption history on each update rather than only new content: When aria-atomic='true' is set and the entire text block is replaced on each update, screen readers attempt to re-read the whole region, causing a jarring experience. Use aria-atomic='false' and append new text nodes so only the new portion is announced.
• Embedding the captions feed in a <canvas> element or as a video overlay graphic: Caption text rendered as pixels on a canvas or burned into a video frame is invisible to assistive technologies. Text alternatives must be provided as actual DOM text nodes.
• Placing the live caption region off-screen with position:absolute; left:-9999px: While visually hiding content in this way keeps it in the accessibility tree, it denies sighted users with hearing loss the ability to read the captions. The text alternative must be visually available to all users, not just screen reader users.
• Failing to identify speakers in multi-speaker broadcasts: A caption feed that transcribes speech without attributing it to specific speakers (e.g., "[Moderator]:", "[CEO]:", "[Audience member]:") is not fully equivalent. Speaker identification is essential for users to follow the conversational structure of a live event.
• Omitting non-speech audio information from the text alternative: Relevant sounds such as applause, technical interruptions, background music, alarms, or laughter carry informational content and must be described in the text feed (e.g., "[applause]", "[technical difficulties — audio interrupted]").
• Providing the text alternative only via a separate third-party URL without embedding it on the same page: Requiring users to open a separate browser tab or window to access captions while the audio plays on the original page creates a significant usability barrier, particularly for screen reader users and keyboard-only users who must switch contexts.
• Assuming that auto-generated captions always meet the equivalence threshold: AI-generated captions can have high error rates with accented speech, technical vocabulary, proper nouns, and fast speech. Deploying uncorrected auto-generated captions for a high-stakes live event (e.g., a medical briefing or financial disclosure) may fail the equivalence standard even if a caption feed is technically present.
• Not testing the live text region with actual screen readers during a live broadcast: Many teams test the player and the caption container in isolation using static placeholder text, but never test the dynamic behaviour during an actual live stream. Bugs in the JavaScript that injects caption updates — such as DOM mutation observers that fail silently — will only surface during live testing.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes binding web accessibility obligations for a broad range of organisations operating in Turkey. The Circular mandates conformance with WCAG 2.2 at the AA level as the baseline standard. The covered entity types include public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools authorised by the Ministry of National Education (MoNE).

WCAG 1.2.9 is a Level AAA criterion, which means it is not among the conformance requirements mandated by the Circular at the AA baseline. Organisations covered by Presidential Circular 2025/10 are not legally obligated to implement live audio-only text alternatives unless they have separately committed to full WCAG 2.2 AAA conformance.

However, several practical considerations make 1.2.9 highly relevant for Turkish organisations even beyond the strict legal minimum. Telecommunications providers, financial institutions, and public broadcasters frequently deliver live audio content — investor calls, public announcements, live customer service broadcasts — that deaf and hard-of-hearing users in Turkey depend on. Demonstrating AAA-level compliance signals a best-in-class accessibility commitment and significantly reduces the risk of discrimination complaints under Turkey's broader disability rights framework, including the Law on Persons with Disabilities No. 5378 and its implementing regulations.

For organisations that voluntarily pursue WCAG 2.2 AAA conformance — whether to differentiate their accessibility posture, to serve international markets with stricter requirements, or to align with procurement criteria that require AAA — implementing 1.2.9 correctly is essential. Accsible recommends that Turkish organisations in regulated sectors proactively assess their live audio content and evaluate the feasibility of integrating CART services or high-accuracy real-time captioning, particularly for public-facing live events where information equity is a concrete stakeholder expectation.