What 1.2.4 is actually asking for

W3C’s Understanding document for 1.2.4 calls for captions for all live audio content in synchronized media. In clerk language: while the meeting is being streamed, the words being spoken have to appear as text, in time with the speaker, so a resident who cannot hear the dais can follow the motion, the discussion, and the vote as they happen.

Two things separate a live caption from a transcript posted the next morning. Timing — the text has to keep pace with the speaker, not arrive seconds behind. Availability — the person watching has to be able to turn captions on in the player they are actually using, on the device they actually have.

1.2.4 sits at Level AA. The 2024 Department of Justice rule under Title II names WCAG 2.1 Level AA as the standard for state and local government web content, and a livestream of a public meeting is web content. That places live captions inside the requirement, not beside it.

Why the livestream is different from the posted file

Everything else Title II asks of meeting video can be corrected afterward. A posted recording can have its captions reviewed, its names fixed, its slides described, its transcript indexed — the file waits for you. A livestream does not. If the captions were missing or unusable at 7:42 p.m. on meeting night, the residents who needed them at 7:42 p.m. did not get the meeting, and no later edit changes that.

Three jobs get collapsed into the phrase “captioned meeting video”:

WhenCriterionWhat it covers
Livestream1.2.4 Captions (live)Real-time captions on the stream, as it happens
File you post1.2.2 Captions (prerecorded)Accurate, synchronized captions on that file
File you post1.2.5 Audio description (prerecorded)Description of important visuals on that file

A town that only captions the recording has handled the second row. The first row — the meeting as it was streamed — is a separate obligation with a separate clock.

Do platform live auto-captions satisfy 1.2.4?

Automatic live captions on a streaming platform are better than nothing, and W3C does not prescribe a technology. The question is whether what residents actually see meets the criterion: text that is present, synchronized, and accurate enough to follow the business of the meeting.

That is where a public meeting is a hard case. The words that carry the decision are the ones generic speech models handle worst: the names of council members and streets, ordinance numbers, “the motion carries,” “abstain,” a roll call read quickly. A caption track that lags several seconds behind the speaker, or that renders a member’s name as a common word, leaves the resident guessing at exactly the moments that matter. Treat platform auto-captions as a starting point to be measured against 1.2.4, not as proof that 1.2.4 is met.

The same accuracy problem shows up on the posted file, which is why YouTube auto-captions are not WCAG 1.2.2 captions either.

What a clerk needs on meeting night

  • Captions that keep pace with the speaker. Synchronized to the person talking, tuned to the names and vocabulary of your town, not a general-purpose model.
  • Captions the resident can reach. A player that lets the viewer turn captions on, works with a keyboard, and works with a screen reader — on a phone in a kitchen, not only on a desktop in the clerk’s office. Section508.gov’s synchronized-media page covers these player-side controls.
  • Nothing extra to install. If residents need an app or an account to see the captions, the captions are not effectively available.
  • A recording that becomes the accessible record. When the stream ends, the file you post picks up the prerecorded criteria: reviewed captions for 1.2.2, description of on-screen materials for 1.2.5, and a searchable transcript.

A clerk’s video checklist puts live captions on their own row, before the posted-file rows, so a meeting does not ship with a captioned recording and an uncaptioned stream.

How Aware Lens handles live captions

Aware Lens Livestream generates captions automatically during the meeting and keeps them synchronized to the speaker, so residents who rely on captions follow in real time rather than seconds behind. Captions can be turned on or off by the viewer; the player is keyboard-operable and screen-reader friendly; residents watch in a browser on any phone or computer with no app and no account.

The town streams from the encoder it already uses — any RTMP encoder, OBS Studio or hardware — with optional YouTube simulcast for residents who already watch there. When the meeting ends, the recording is processed into the same accessible record as every other Aware Lens meeting: corrected captions, a synced transcript, audio description, and a plain-language summary, searchable alongside the town’s archive. It supports your ADA Title II and Section 508 compliance efforts for live and recorded public meetings.

Start with your next live meeting. That is the one 1.2.4 is measured on.

Book a 20-minute demo. We will go live on your own portal and show the captions keeping pace with the speaker.

The rest of Title II for meeting video — dates, 1.2.2, 1.2.5, archives — is on ADA Title II meeting video.

Sources

Product explanation, not legal advice. Confirm 28 C.F.R. Part 35 and current ADA.gov materials before you rely on them.