# Live radio streams with no live text

Source: https://easeweb.dev/learn/live-audio
Topics: Images and media > Live audio has a text alternative (WCAG 1.2.9)
The fix: Book a live captioner (CART) for the broadcast and show their live text in a frame right beside the player. Where the host reads a prepared script and keeps to it, the script on the page is enough, but only for what is in it.
Test with: sound off, screen reader
References: https://www.w3.org/WAI/WCAG22/Understanding/audio-only-live.html https://www.w3.org/WAI/WCAG22/Techniques/general/G150 https://www.w3.org/WAI/WCAG22/Techniques/general/G151 https://www.w3.org/WAI/WCAG22/Techniques/general/G157 https://www.w3.org/WAI/media/av/captions/ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe

This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.

## What happens

Riverside Radio, a community station, streams its morning news live from its website. A Listen live player sits under the day's programme, and nothing else. At eight o'clock the host says that Mill Road bridge is closed from ten for repairs, that buses 4 and 7 will go along Station Street instead, and that the farmers' market moves to the school car park this Saturday. Then, after a jingle, a change comes in: the market moves on Sunday, not Saturday. A Deaf visitor presses Play, sees the elapsed time count up, and learns nothing. A visitor on a phone with the sound off meets the same silence. The news is for this morning, so a recording or a transcript posted later is too late for the bridge and the buses.

## Why it fails

Success criterion 1.2.9, at Level AAA, asks for a text alternative for live audio-only content, such as a radio stream or a live audio event, that presents equivalent information while it is live. The usual way is a live caption service, sometimes called CART: a trained captioner listens and types what is said in real time, a few seconds behind, with notes on sounds that matter. The text is shown in a viewport on the same page as the live audio (technique G157). Where a broadcast follows a prepared script, the script can serve, but only while the broadcast keeps to it (technique G151). The browser plays a stream as sound and nothing more: an `<audio>` element has no way to show live text by itself. Here the page offers no text at all, so it fails.

W3C notes that the criterion is not meant to require captions on two-way audio calls between people in a web app. It is about broadcasts: a radio stream, a live podcast, a live audio event.

## Who is affected

Live audio moves on at the host's pace. Unless the player can rewind, whatever is missed while the host reads on is lost for the broadcast, and the news on a morning show matters most that morning.

## What automation and AI miss

No scan can listen to a stream, or check before it starts that someone will type it live. axe has no rule for 1.2.9. EaseWeb's audit loads each `<audio>` player's details, and one whose stream has no end, as this one has, goes to review as live audio under 1.2.9 rather than as a recording that needs a transcript. Whether live text will be there, and whether it is right, can only be checked during a broadcast or a rehearsal. Automatic speech recognition can produce live text with no person, but it can mishear names and numbers and drop a "not", which on this show turns "Sunday, not Saturday" into the wrong day. W3C's guidance on 1.2.9 says untrained operators, or text that differs markedly from what is said, don't meet it.

## Before: a live player with nothing to read

```html
<h2>Listen live</h2>
<p>Morning news, every weekday from 8:00 to 8:30.</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
```

- The news exists only as live speech.
- A visitor who can't hear it gets a play button and a time counting up.
- The bridge closure, the bus diversion and the market's change of day never reach them.

## After: a captioner's live text beside the player

```html
<h2>Listen live</h2>
<p>Morning news, every weekday from 8:00 to 8:30.
  Live text, typed by a captioner, appears under the player.</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
<iframe title="Live text of the morning news"
  src="https://captions.example.com/live/riverside-radio"></iframe>
```

1. Book a live captioner for the broadcast. They listen to the stream and type what is said, a few seconds behind, with sounds that matter in brackets.
2. Captioning services give each broadcast a page where the text scrolls as it is typed. Put it in a frame right after the player, titled so a screen reader says what it is.
3. Say beside the player that live text, typed by a captioner, appears under it.

This fixes the Before and passes 1.2.9 (technique G157). Everything the host says reaches the page as text while it is still news, the change that came in during the show included. The text follows a few seconds behind the voice, and G157 asks only that it arrive in less than 30 seconds.

## After: the prepared script on the same page

```html
<h2>Listen live</h2>
<p>Morning news, every weekday from 8:00 to 8:30.</p>
<audio controls preload="none"
  src="https://stream.riverside.example/live.mp3"></audio>
<details>
  <summary>This morning’s news, as prepared</summary>
  <p>Good morning, it’s eight o’clock, and this is Riverside Radio.</p>
  <p>Mill Road bridge is closed from ten this morning, for repairs.</p>
  <p>Buses 4 and 7 will go along Station Street instead.</p>
  <p>And the farmers’ market moves to the school car park this Saturday.</p>
  <p>The host may add news that comes in during the show.</p>
</details>
```

1. Publish the script the host reads from, in HTML, on the same page as the player, so opening it doesn't stop the stream.
2. Put it right after the player, in a `details` whose summary says it is the news as prepared.
3. End it by saying that the host may add news during the show.

This fixes the Before and passes 1.2.9 (technique G151), but only while the host keeps to the script. Here the host doesn't: the change of day comes in after the script was written, so the script still says Saturday, and a visitor who reads it goes on the wrong day. The script also can't show where the broadcast has got to. It suits a pre-written bulletin, a reading or a radio play that keeps to its text, not a show with news coming in, callers or chat.

## Which option to use

Both pass 1.2.9 for what they cover. Use a captioner's live text: it carries whatever is said, including what nobody planned, while the script covers only what was written beforehand. The script is a fair addition even with a captioner: it is exact where the live text may slip, and it gives names and numbers spelled out. Rely on it alone only for a broadcast read word for word from it.

## Implementation decisions

Book the captioner when you plan the broadcast. Real-time captioners can work remotely, from the audio over a phone line or the internet, and need the material in advance: presenters' names, place names, and any script. For a station that broadcasts all day, captioning every hour costs more than captioning the news and the programmes people rely on most. Start with those, and say on the page which programmes have live text.

The frame is the captioning service's page, so how it behaves is theirs to get right: text that keeps its place while new lines arrive, a size the visitor can change, and a page a screen reader can read. Check it with a screen reader before you rely on it. If the text should also reach visitors on a braille display as it arrives, ask the service whether its page announces new lines, since a frame of scrolling text is otherwise silent until someone reads it.

Automatic speech recognition can feed live text with no person, and some stations use it for round-the-clock streams. It is better than nothing for programmes nobody captions, but it is not how a station meets 1.2.9 for its news: it can get names and numbers wrong, and nobody checks it before it is shown. The same holds for live video, covered in [live streams with no captions, or only automatic ones](/learn/live-captions).

When the show ends and a recording goes up for listening again, it is prerecorded audio, and [podcasts and silent videos with no transcript](/learn/transcripts) applies: the captioner's text, corrected against the recording, is a good start for its transcript. A live stream with video, such as a webinar, needs live captions in the player instead (1.2.4).

## Verify the fix

1. During the broadcast, or a rehearsal with the captioner, watch the live text against the stream: it keeps up within a few seconds, and keeps going to the end of the programme.
2. Turn the sound off and read only the text for several minutes. Names, street names, numbers, days and every "not" are right, and the sounds that matter are in brackets.
3. Where a script stands in for live text, listen to the whole broadcast with the script open. The host keeps to it, and nothing that matters is said off it.
4. With a screen reader, read on from the heading above the player. The live text, or the summary that opens the script, comes next and says what it is.

Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat for each programme that has live text, and whenever the captioning service changes.

## Limits

This is a starting pattern, not a guarantee for every application. Whether live text is right can only be checked live, and this guide can't do that for you. Live video, such as a webinar, needs live captions (1.2.4), covered in [live streams with no captions, or only automatic ones](/learn/live-captions). Prerecorded audio, such as the show's recording, needs a transcript (1.2.1), covered in [podcasts and silent videos with no transcript](/learn/transcripts). Sound that starts by itself is covered in [autoplaying sound with no way to stop it](/learn/autoplay-audio). Test the complete journey with the people who will listen and read, on the devices they use.

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)