WCAG Success Criterion 1.2.2 requires captions for prerecorded audio content. Section 508 and a growing list of state and international accessibility rules point back to the same requirement. None of them grade the captions once they exist. A track can satisfy every "does it have captions" check in existence and still be unreadable to the person it was made for.
A caption file passes "presence" the moment it parses, syncs to the video, and displays something. None of that says whether a viewer can actually read a given cue before it changes. That is a function of exactly two numbers — how many characters are on screen, and for how long — and a caption track can fail it while being a perfectly accurate transcription of the audio.
Automatic speech recognition optimizes for transcription accuracy: getting the words right. It has no model of how fast a human reads. It breaks caption blocks on pauses in the audio track, not on a target character count, so a dense, fast-talking passage produces a caption block that is word-for-word correct and reads at a speed nobody can follow. The rise of auto-captioning has made "does it exist" trivially easy and "is it readable" no more solved than before — if anything, the gap between the two questions has gotten wider, not narrower.
There is no single legal reading-speed limit the way there is a legal blood-alcohol limit. What exists instead is a convergent set of numbers across several independently-published caption style guides — Netflix's public Timed Text Style Guide and the BBC's Subtitle Guidelines both publish figures in the same neighborhood: a reading-speed ceiling in the high teens to low twenties of characters per second, a two-line maximum per cue, and minimum/maximum on-screen durations in roughly the same range. None of these guides has legal force outside its own platform's contracts. They are cited here as commonly-used industry defaults, not as one controlling standard — which is also why every threshold in this tool is configurable.
Stretching a cue's on-screen time lowers its characters-per-second reading speed, and it is the first fix most people reach for. It has a ceiling: a cue left on screen too long (past a commonly-used ceiling around seven seconds) invites the viewer to re-read it, and by then the dialogue and the picture have both moved on — the caption stops matching what is happening on screen. When a line is genuinely too dense to read in a reasonable time, the more durable fix is usually to shorten the wording, not to hold the cue open longer.
Reading speed, line length, lines per cue, minimum/maximum duration, overlaps, and gaps are all mechanically computable from the timestamps and text a caption file already contains — no judgment call, no audio needed. Caption Quality Checker runs those checks: paste an SRT or WebVTT file, or run the CLI against a file on disk and wire it into CI as a regression gate on every future upload.
Accuracy and readability are two different properties, and an automatic speech-recognition system optimizes for accuracy, not for the pacing a human reads at. It breaks cues on pauses in the audio, not on a target reading speed — so a fast talker can produce a caption block dense enough to be technically correct and still impossible to finish reading before the next cue replaces it. The transcription can be word-for-word right and the caption track can still fail its own audience.
Usually nobody, mechanically. A video platform's own upload validator checks that a caption file parses and that timestamps are well-formed — it has no opinion on whether a cue is readable in the time given. A human style-guide reviewer at a large broadcaster or streaming platform checks this by eye, cue by cue, which is exactly the kind of repetitive check a deterministic tool should be doing before a human ever looks at the file.
Only up to a point, and it trades one problem for another. Stretching a cue's duration lowers its characters-per-second, but a cue left on screen for too long (past the commonly-used ~7-second ceiling) invites re-reading and desyncs the viewer's attention from the picture — especially if the dialogue underneath has already moved on. The better fix, when a line is genuinely too dense, is usually to shorten the wording rather than to stretch the timing.