WCAG 1.2.4: Captions (Live)

Who this helps

The primary beneficiaries are people who are deaf or hard of hearing. For prerecorded media they can wait for a captioned version or a transcript; for a live event there is no later — either the captions are there during the broadcast or the person is shut out of the Q&A, the vote, the announcement, the game. Live events are also precisely where participation matters: you cannot ask a question in a webinar you could not follow.

Live captions also serve a much wider audience: people watching in loud environments (a commute, a factory floor) or in silence (a shared office, next to a sleeping child), non-native speakers who parse written language more easily than rapid speech, and viewers coping with poor audio quality on a shaky connection. Caption usage among hearing viewers is consistently high — the accessibility requirement and the mainstream feature are the same work.

What the requirement covers

If your site presents live synchronized media — a webcast, a streamed conference session, a live product launch, a webinar, a streamed religious service or council meeting — captions must be provided for all of its audio content. Good live captions:

• →Convey the speech: what is said, by whom (speaker identification when it is not visually obvious), as close to verbatim as real-time production allows.
• →Convey essential non-speech audio: [applause], [buzzer], [phone ringing], [laughter] — any sound a hearing viewer would use to understand the event.
• →Stay synchronized: a few seconds of delay is inherent to real-time captioning, but captions that lag far behind the video make dialogue impossible to match to speakers.
• →Are readable in the player: viewers should be able to turn them on easily, and player caption settings (size, colors) should apply to them.

How teams produce live captions

And remember the hand-off: the moment the recording of your live event is published, it is prerecorded media — 1.2.2 Captions (Prerecorded) then requires captions on the recording, and this is your chance to clean up any live captioning errors.

Pass and fail examples

• ✓Pass — Webinar with CART captioning. A public product webinar streams with a professional real-time captioner (CART) producing captions that appear in the player within a few seconds, identify speakers, and note audience reactions.
• ✓Pass — Live stream with corrected ASR. A conference keynote uses automatic speech recognition with a human editor fixing names and jargon in real time. The resulting captions accurately convey the speech and key sounds.
• ✗Fail — Town hall stream with no captions. A city council streams its public meeting live with audio and video but offers no captions at all. Deaf and hard-of-hearing residents cannot follow the proceedings.
• ✗Fail — Captions that don't convey the content. A live sports webcast enables unmonitored auto-captions that garble player names and drop whole sentences during fast commentary. Captions exist, but they are not an equivalent for the audio.
• ✗Fail — Transcript posted afterwards only. A live investor call promises a transcript 'within 48 hours'. A post-hoc transcript does not caption the live audio content — during the event, deaf viewers were excluded.

Implementation examples

Live captions are mostly a production and platform choice, but the delivery layer is code. In HLS streams, captions travel either as embedded CEA-608/708 tracks or as a WebVTT subtitles rendition declared in the multivariant playlist.

Declare the caption track in your HLS playlist

# ✗ Failing: video/audio renditions only — no caption track anywhere
#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
video_720p.m3u8

# ✓ Passing: live WebVTT subtitles rendition, linked to the stream
#EXTM3U
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",NAME="English",\
  LANGUAGE="en",AUTOSELECT=YES,URI="captions_en.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,SUBTITLES="subs"
video_720p.m3u8

Make sure your player exposes the captions

A caption track your player never surfaces is a fail in practice. Most JavaScript players pick up in-manifest tracks automatically — verify the CC button exists and works on the live stream, not just on VOD.

// Example: hls.js — confirm subtitle tracks are found and enabled
const hls = new Hls({ enableWebVTT: true, enableCEA708Captions: true });
hls.loadSource("https://cdn.example.com/live/master.m3u8");
hls.attachMedia(videoElement);

hls.on(Hls.Events.SUBTITLE_TRACKS_UPDATED, (_evt, data) => {
  console.log("Caption tracks:", data.subtitleTracks); // must not be empty
  if (data.subtitleTracks.length > 0) hls.subtitleTrack = 0;
});

Offer a visible caption fallback when the player cannot render them

Some events pipe CART output to a separate caption view. If you render a live text stream alongside the video, keep it in reading order near the player and clearly labeled.

<!-- Live CART feed rendered next to the stream -->
<div class="stream-layout">
  <video id="live-player" controls></video>
  <section aria-label="Live captions" class="cart-panel">
    <h2>Live captions</h2>
    <div id="cart-output" class="cart-text">
      <!-- caption lines appended here by the CART provider's script -->
    </div>
  </section>
</div>

Common failures

• ✗Streaming live events — webinars, launches, meetings — with no captioning arranged at all.
• ✗Promising a transcript or captioned recording after the event instead of captioning the live broadcast itself.
• ✗Relying on raw, unmonitored auto-captions that mangle names and technical terms until the captions no longer convey the content.
• ✗Captions without speaker identification in multi-speaker events, leaving viewers unable to follow the conversation.
• ✗Omitting meaningful non-speech audio — the [alarm], the [applause], the [bell] that changes the meaning of what is happening.
• ✗Publishing a caption track the player never exposes: the CC button is missing or does nothing on the live stream.
• ✗Captioning the main presentation but not the Q&A, panel discussion, or breakout portions of the same live event.
• ✗Testing caption delivery only on VOD content and discovering during the event that the live pipeline drops the track.

How to test for 1.2.4

1. 1

   Inventory your live media

   List everything the site broadcasts live with both audio and video: webinars, streamed events, live shopping, town halls. Each item on the list needs a captioning plan; 'we didn't think of that stream' is the most common failure.

2. 2

   Watch a live event with the sound off

   The core test. Join the stream muted and try to follow it entirely from the captions. Can you tell who is speaking? Do you learn about audience reactions and other sounds? Would you be able to participate in the Q&A?

3. 3

   Check caption quality, not just presence

   Compare a few minutes of captions against the actual speech. Count errors on names, numbers, and domain terms — these are exactly what ASR gets wrong and exactly what the audience needs right.

4. 4

   Verify the player exposes and renders the track

   On the live stream (not a recording), confirm the captions control is present, keyboard-operable, and actually displays captions. Test the browsers and devices your audience really uses.

5. 5

   Run a rehearsal with the captioning in place

   Live captioning is a pipeline: audio feed → captioner/ASR → encoder → player. Rehearse the full chain before the event, including a fallback plan (e.g., a CART web view link) if the in-player track fails mid-broadcast.

Automated accessibility scanners cannot see inside a live stream — this criterion is verified by process and rehearsal. Pair it with the rest of the time-based media criteria in the WCAG 2.2 checklist.

Frequently asked questions