1.2.4 Captions (Live)
- Level AA
- Perceivable
- Since WCAG 2.0
Summary
Live captions exist for people who are deaf or hard of hearing and would otherwise be shut out of a live event entirely: there is no pause button, no second chance, and no transcript to read afterwards while the event still matters. This criterion, at Level AA since WCAG 2.0, requires captions for all live audio content in synchronized media: live video streams, webinars, town halls, live shopping events, and any other real-time presentation that combines audio with video or interaction.
The auditor's mental model has two parts. First, scope: the criterion covers synchronized media only, so a live audio-only broadcast (web radio, an audio-only space) is technically outside this criterion at Level AA, however unsatisfying that feels. Second, the quality bar: live captioning is judged realistically. Some latency behind the speaker and occasional minor errors are inherent to real-time captioning and do not fail the criterion, provided the captions keep pace well enough to follow and the meaning of what is said is preserved. Auto-captioning services are acceptable on the same test: if the accuracy holds, the criterion is met; if the output is garbled to the point that meaning is lost, it is not.
Official wording
Captions are provided for all live audio content in synchronized media.
EN 301 549 mapping
- Web pages
- Clause 9.1.2.4
- Software and native apps
- Clause 11.1.2.4
Clauses 9.1.2.4 (web) and 11.1.2.4 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Testing this criterion means joining a live session, not inspecting a static page. Identify everything on the site that broadcasts live: scheduled webinars, embedded live streams, live events in a media player, live customer Q&A sessions. Schedule the audit step around a real broadcast, or ask the organisation to run a test stream through the same pipeline they use in production.
During the session, check two things. Availability: the player exposes a caption toggle (usually a CC button) and turning it on produces captions during the live portion, not just on the replay. Quality: watch a representative stretch with sound on and compare. Captions should identify who is speaking where that is not obvious, keep up with the audio closely enough to follow the discussion, and preserve meaning; note latency and error rate in your evidence, but grade against comprehension rather than perfection. In browser devtools you can confirm a live text track is actually being delivered (for example, caption cues updating in the player's track), which distinguishes a working pipeline from a decorative CC button.
Common web failure spots: embedded third-party players where the host site never enabled the caption track, caption toggles that appear but receive no live cue data, events captioned only in the post-event recording, and picture-in-picture or minimised player modes that drop the caption display.
iOS
The criterion applies unchanged to software under the European standard, so live features inside an iOS app are graded the same way as a live stream on the web. Find the app's live surfaces: live video, in-app webinars, live shopping, real-time broadcasts in a community feature. Join a session on a device and check that the in-player experience offers captions and that they render during the live broadcast: a caption control in the player UI, cues appearing in time with speech, and readable presentation when the player is rotated or resized.
One boundary matters more on iOS than anywhere else. iOS provides Live Captions as a system accessibility feature that generates device-side captions for any audio. That is a user tool, and it does not discharge the author's obligation under this criterion: the app must provide captions for its live audio content itself. The parallel is exact with platform autofill elsewhere in WCAG grading: what the user's device can do to rescue the experience is not what the author has provided. Grade the app's own live captioning, and do not accept "users can turn on Live Captions" as a pass.
Use the session itself as evidence: screen recordings showing the caption toggle, the live cues alongside the video, and a stretch of audio for quality comparison.
Android
The same logic applies on Android. Locate live features in the app, join a broadcast, and verify the player offers a working caption control with live cues that keep pace and preserve meaning. Media players built on the platform's standard media components support timed text tracks, so the question for the auditor is whether the app's live pipeline actually delivers a caption track to the player, not whether the player could theoretically show one. A CC button that renders nothing during the live event is a fail regardless of what the replay later offers.
Android ships Live Caption, a device feature that transcribes any audio on the device using on-device speech recognition. As with iOS Live Captions, this is a user tool: it belongs to the person, not the product, and its existence does not satisfy this criterion. It is also worth separating in your notes, because a tester who forgets Live Caption is switched on can mistake device-generated captions for the app's own and record a false pass. Turn the device feature off before grading.
Common Android failure spots: live streams delivered without any embedded or sidecar caption track, caption rendering that breaks in fullscreen or picture-in-picture, and live events captioned only in the recorded version published afterwards.
Pass and fail examples
Passes:
- A public webinar with a professional real-time captioner: captions run a few seconds behind the speakers and occasionally correct themselves, but the discussion is fully followable. Latency of that kind is inherent to live captioning and does not fail.
- A live product stream using an automatic captioning service whose output holds up: speaker changes are clear, terminology is mostly right, and meaning is preserved throughout. Auto-captioning is acceptable when the accuracy holds.
- An in-app live shopping event where the player has a caption toggle and live cues render in sync on both phone and tablet layouts.
Fails:
- A live quarterly all-hands streamed on the website with no captions at all, on the promise that a captioned recording will be published later. The live event is the content this criterion covers, and it shipped without captions.
- A player that shows a CC button during the live broadcast, but toggling it produces nothing because no live caption track is being delivered.
- Auto-generated live captions so inaccurate that names, figures, and key points are mangled beyond recovery: the captions exist, but the meaning of the audio is not being conveyed.
- An Android app whose team points to the device's Live Caption feature instead of providing captions: user tools do not discharge the author's obligation.
Not a fail under this criterion:
- A live audio-only broadcast, such as web radio or an audio-only live room, with no captions: audio-only live content is outside the scope of this criterion at Level AA (SC 1.2.9 Audio-only (Live) covers it at Level AAA). Record it as a best-practice recommendation, not a 1.2.4 fail, and say so honestly in the report.
- A prerecorded video published without captions: that finding belongs to SC 1.2.2 Captions (Prerecorded).
- Captions that trail the speaker by a few seconds or contain occasional minor errors while meaning is preserved: that is the realistic quality bar for live captioning, not a defect.
Commonly confused with
- SC 1.2.2 Captions (Prerecorded). The dividing line is whether the audience experiences the media in real time. A live webinar is 1.2.4; the recording of that webinar, once published, is prerecorded media and its caption obligations attach under 1.2.2 and its siblings. Audit both moments separately: a captioned replay does not repair an uncaptioned live event, and a captioned live event does not exempt the uncaptioned recording.
- SC 1.2.9 Audio-only (Live). The Level AAA criterion that covers live audio-only content, such as web radio. Auditors sometimes file uncaptioned audio-only streams under 1.2.4; the "synchronized media" scope excludes them at AA. Note the gap honestly and recommend a text alternative as good practice.
- Platform live-caption features (iOS Live Captions, Android Live Caption). These are user-side tools that transcribe audio on the person's own device. They are excellent assistive features and entirely irrelevant to conformance: the author must provide captions for live synchronized media. Citing the device feature as a pass is the most common false pass on this criterion in app audits.
- SC 1.2.1 Audio-only and Video-only (Prerecorded). Handles prerecorded audio-only and video-only material via alternatives, not captions. A finding about a prerecorded podcast episode belongs there, not under either captions criterion.
How AUDITSU tests this
AUDITSU's audit walkthrough flags media capabilities as you review each screen, and live media triggers this criterion's checks: whether the product broadcasts live synchronized media, whether the player offers captions during the live event, and whether the caption quality preserves meaning at a realistic live standard. Because live content cannot be tested from a screenshot, the walkthrough is designed to record evidence from a joined session (the caption toggle, live cues in the player, and notes on latency and accuracy), with a pass, fail, or not applicable result per screen so the finding stays tied to the exact feature.
The criterion applies unchanged to web and software under the European standard, so the same walkthrough questions cover a browser-based webinar and a native app's live feature, including the check that device caption tools were switched off before grading.
For the full guided workflow, see the audit platform.