Search topics
Live radio streams with no live text
A community radio station streams its morning news live with nothing to read, so road closures and a change made during the show reach only those who can hear.
<audio controls src="https://stream.riverside.example/live.mp3"> The problem
People who can't hear the stream miss the road closures, the bus changes and the change that comes in during the show
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.
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.
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.
3 of 10 groups affected
- No vision (not affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (affected)
- Hard of hearing (affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without hearing The bridge closure, the bus diversion and the market's new day are only spoken. With nothing to read, they never reach a Deaf visitor, who can't wait for a recording either: the news matters this morning.
- Limited hearing A stream through a phone speaker, or a host who reads fast, is hard to follow live, and a plain live stream has no way back to a line just missed. Reading along fills in the street names and the day they half heard.
- Limited language, cognitive and learning abilities Text lets people who take in speech slowly, or listen in a second language, read a street name or a time again instead of losing it as the host moves on.
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.
Try it
Turn the sound off and play the live stream. When does the farmers’ market move?
The switch stands in for a listener who can’t hear: the stream still plays, and tells you nothing. The recording here stands in for a live stream, so the player shows its length.
Apply a fix to read live text typed by a captioner as the host speaks, or the script as prepared. Listen to the end with each.
Broken Can you fix this?
Listen live
Morning news, every weekday from 8:00 to 8:30.
The fix
Show the broadcast as text while it is live
<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>What is wrong3 points
- 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.
A captioner's live text beside the player
<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>How it is fixed3 steps
- 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.
- 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.
- 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.
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.
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.
When the show ends and a recording goes up for listening again, it is prerecorded audio, and podcasts and silent videos with no transcript 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
4 checks, no mouse.
Test with: Sound off, Screen reader
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. Prerecorded audio, such as the show's recording, needs a transcript (1.2.1), covered in podcasts and silent videos with no transcript. Sound that starts by itself is covered in autoplaying sound with no way to stop it. Test the complete journey with the people who will listen and read, on the devices they use.
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.
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.