WCAG 1.2.4 — Captions (Live)

What this requires

Any live audio content in synchronised media must have captions provided in real time. The user watching a live webinar, an all-hands stream, a conference keynote, or a live product event needs the captions while it's happening — not afterwards in the recording. The caption stream must include speaker identification and relevant non-speech audio just like prerecorded captions, and must be visible to all viewers (not gated behind a separate URL or device).

How AI coding tools fail this

When asked to "add a live stream to the events page", AI tools wire up the embed (a YouTube Live iframe, a custom HLS player) without configuring or even mentioning captions. The platform's live-captioning feature has to be enabled deliberately, and the generated code rarely surfaces that as a step.

The second pattern: custom video players assembled with <video> + HLS.js or Shaka Player, with no <track> handling and no plumbing to ingest a live caption feed. The player works; the caption stream has no home.

The third: assuming the platform's auto-captions are sufficient without verifying the language is set correctly. Auto-captions defaulting to English on a Spanish-language stream is the same failure pattern as 3.1.1, dressed differently.

Failing examples

A live YouTube embed with no caption configuration:

<iframe
  src="https://www.youtube.com/embed/live_stream?channel=ACME"
  title="ACME live"
  allow="encrypted-media"
/>

A custom HLS player with no caption track plumbing:

<video controls>
  <source src="https://stream.example/live.m3u8" type="application/x-mpegURL" />
</video>

Passing examples

A live stream on a platform with live captions enabled, with the caption visibility on by default:

<iframe
  src="https://www.youtube.com/embed/live_stream?channel=ACME&cc_load_policy=1&cc_lang_pref=en"
  title="ACME launch — live with captions"
  allow="encrypted-media"
/>

A custom player with a live WebVTT caption stream wired in:

<video controls>
  <source src="https://stream.example/live.m3u8" type="application/x-mpegURL" />
  <track
    kind="captions"
    src="https://stream.example/live.vtt"
    srcLang="en"
    label="English"
    default
  />
</video>

Edge cases

Live auto-captions from a major platform (YouTube, Zoom, Teams, Webex) generally satisfy the criterion for general-audience content, but they are noticeably worse for technical vocabulary, accents, and multi-speaker audio. Plan for human captioners on high-stakes events.
Captions for the recording (after the stream ends) are a prerecorded-captions concern (1.2.2), not 1.2.4. Both apply when you publish the recording.
Audio-only live streams (a live radio show, a live podcast) are not synchronised media — 1.2.4 doesn't apply, but you still need a text equivalent of some kind for the live audio to be perceivable to deaf users.
Sign-language interpretation counts toward the criterion only if it appears for all viewers, not behind a separate stream.
In-house live captioners ("CART" — Communication Access Real-time Translation) are the gold standard for accuracy on professional events.

How Jeikin handles this

Live-stream accessibility can't be inspected from static markup alone — the captions exist (or don't) at runtime, not in the HTML. Jeikin tracks 1.2.4 as a manual review item: the dashboard lets the reviewer record, per event, whether captions were enabled and which captioning method was used. The evidence is the answer log, not an automated check.