Captions under the ADA Title II web accessibility rule
Updated
The Department of Justice rule published on 24 April 2024 requires state and local governments, including public schools, universities, libraries and courts, to make their web content and mobile apps conform to WCAG 2.1 Level AA. Entities serving 50,000 people or more had until 24 April 2026. Smaller entities and special district governments have until 26 April 2027. WCAG 2.1 AA requires captions on prerecorded and live video, and captions in WCAG's sense means accurate, synchronised text covering speech and the sounds that matter, not an unchecked auto-caption track. This page describes the rule. It is not advice about your obligations under it.
Who it covers, and from when
Title II of the ADA covers state and local government entities and the bodies they run: cities and counties, state agencies, public K-12 schools, public colleges and universities, public libraries, transit authorities and courts. The 2024 rule is the first time the technical standard for their web content has been written down, and the standard it picks is WCAG 2.1 at Level AA.
The rule took effect on 24 June 2024 with two compliance dates. Entities with a population of 50,000 or more had until 24 April 2026, which has passed. Entities under 50,000, and special district governments of any size, have until 26 April 2027. Private businesses fall under Title III, and as of this guide's date there is no equivalent rule for them.
It applies to content the entity provides or makes available, including through a third-party platform. A council meeting the city posts to its own video channel is the city's web content. The hosting platform's built-in captions do not change who is responsible for them.
What WCAG 2.1 AA asks of video
The success criteria that touch video are few, and worth reading in the original once rather than through a vendor's summary.
- 1.2.1, at Level A: a text or audio alternative for prerecorded audio-only and video-only content
- 1.2.2, at Level A: captions for all prerecorded video with sound. This is the one that covers nearly everything a public body publishes
- 1.2.3, at Level A: audio description or a full text alternative for prerecorded video
- 1.2.4, at Level AA: captions for live video. A live-streamed meeting needs them while it is live, which is a different service from captioning a recording afterwards
- 1.2.5, at Level AA: audio description for prerecorded video, which captions do not satisfy and no transcription tool produces
Why an unchecked auto-caption track does not meet it
The rule sets no accuracy percentage, and it is easy to read that as permission. It is the opposite. WCAG defines captions as synchronised text for both the speech and the non-speech audio a viewer needs, including who is speaking when that is not obvious. Text that misnames the people in a hearing, drops the vote count, or skips the point where the room laughed is not captions in that sense. It is a draft.
That is the right way to think about any machine transcript, including the one this tool produces. The dialogue will be mostly right and the proper nouns will be where the errors cluster, because the model has never heard your councillors' names. Someone has to read it against the recording, and the budget for that review is the real cost of compliance, not the software.
Reading speed is the other place a verbatim transcript fails. The convention is at most 17 characters a second, and a fast speaker transcribed word for word runs past it. Every cue here is checked against that limit and flagged, so the review is a list of flags rather than a count by hand.
The exceptions, read carefully
The rule exempts five kinds of content, and each one is narrower than it sounds.
- Archived web content, but only if it was created before the compliance date or reproduces older physical material, is kept solely for reference or recordkeeping, sits in a clearly identified archive area, and has not been changed since it was archived. Next month's meeting recording fails the first test
- Conventional electronic documents such as PDFs and Word files that existed before the compliance date, unless they are currently used to apply for or take part in a service
- Content posted by a third party, unless it was posted under a contract or licence with the entity
- Individualised, password-protected documents about a specific person or account
- Social media posts made before the compliance date. Posts after it are covered, which includes a video clip of a meeting posted to a public feed
Where a tool like this fits, and where it does not
It produces the draft. Drop the meeting recording in, and the transcript comes back as a timed caption file, WebVTT for a web player or SRT for everything else. A two-hour meeting is the ceiling, at 2 hours per recording, and at the measured 8.6x on WebGPU an hour of audio takes about 8 minutes. A longer meeting is split in two first.
What it does not do is the part that makes a draft into captions: checking the names, adding the sound cues, marking speakers where the picture does not show them. Those are edits in the same editor, against the waveform, and they take a fraction of the meeting's length. Live captioning is outside what a browser tool does at all. That is a real-time service with a human or a dedicated system behind it.
The reason to do the draft locally is specific to public bodies. A closed session, a personnel hearing or a recording with a resident's medical details is not something to send to a transcription vendor on a free trial. Here nothing is sent, so there is no vendor, no agreement to sign, and no copy of the recording anywhere but the machine it was already on.