WCAG 1.2.9 — Audio-only (Live)

What this requires

For live audio-only content at Level AAA, a text alternative must be provided in real time. This applies to live audio streams that are not part of synchronised media — a live audio-only event, a Twitter Spaces-style room, a live audio talk page, a phone-in broadcast. The alternative is typically a live transcription stream (CART) or a real-time captioning panel displayed alongside the audio interface.

How AI coding tools fail this

When asked to "add a live audio room" or "build a live podcast page", AI tools generate the audio player and a "now live" indicator and stop. The real-time transcript stream is treated as a separate infrastructure problem — which it often is — and the UI never makes room for it.

The second pattern: an audio-only live stream embedded as <audio> with no surrounding live region or transcript area. Even when the platform provides a live transcription endpoint, the consuming page doesn't wire it up.

The third: treating "we'll publish the recording later with a transcript" as an answer. That covers the prerecorded version, not the live one.

Failing examples

A live audio embed with no transcript surface at all:

<audio controls autoPlay>
  <source src="https://stream.example/live.mp3" type="audio/mpeg" />
</audio>

A "transcript coming after the show" framing presented as an accessibility solution for the live event:

<>
  <audio controls src="https://stream.example/live.mp3" />
  <p>A transcript will be available within 48 hours.</p>
</>

Passing examples

A live audio stream paired with a live transcript region (driven by a real-time captioning service or platform feature):

<>
  <audio controls>
    <source src="https://stream.example/live.mp3" type="audio/mpeg" />
  </audio>
  <section aria-labelledby="live-transcript-heading">
    <h2 id="live-transcript-heading">Live transcript</h2>
    <div
      role="log"
      aria-live="polite"
      aria-atomic="false"
      className="max-h-80 overflow-auto"
    >
      {transcriptLines.map((line) => (
        <p key={line.id}>
          <strong>{line.speaker}:</strong> {line.text}
        </p>
      ))}
    </div>
  </section>
</>

Edge cases

Audio-only live ≠ video live. Captions on synchronised media are 1.2.4; 1.2.9 is for the audio-only case.
Crowd-sourced live transcripts (a live community typing along) technically count if they keep up with the audio — but they're fragile. Use a dedicated captioning service for serious events.
role="log" with aria-live="polite" is the right pattern for the transcript area: new lines are announced to screen readers without interrupting the current utterance.
Latency tolerance: a few seconds of lag is acceptable; tens of seconds is not. The transcript must be usable as a real-time alternative.
Recording for later is not the same accessibility need. The recorded version falls under prerecorded audio-only (1.2.1).

How Jeikin handles this

This is a manual review item, evaluated per live event rather than per page. The dashboard records, for each live audio event, whether a real-time transcript was provided and through which mechanism. The evidence is the event log, not an automated check.