Offline Caption QC vs Live Auto-Captions

A live auto-caption is a best-effort overlay on a stream that has not finished yet. An offline caption is a checked transcript aligned to a file that will be replayed. Treating them as the same deliverable is how a webinar's ASR dump gets copied onto an evergreen course and shipped as "captioned."

The standards already split the work. WCAG 2.2 Success Criterion 1.2.2 Captions (Prerecorded) is Level A: captions for all prerecorded audio in synchronized media. SC 1.2.4 Captions (Live) is Level AA: captions for live audio in synchronized media. Same word, "captions." Different clocks, different error budgets, different QC.

Two clocks, two products

Live, in WCAG, means information captured from a real-world event and transmitted with no more than a broadcast delay. If the information is completely computer generated, it is not live. The FCC uses a similar split for television: 47 CFR § 79.1 defines live programming as shown substantially simultaneously with its performance, near-live as performed and recorded less than 24 hours before first air, and prerecorded as everything else.

That clock is the product difference.

Live auto-captions (automatic speech recognition on the wire, or a stenographer following the talker) cannot look ahead. They guess the current word, they lag the audio, and they cannot know a proper noun until it has been said. SC 1.2.4 still requires captions that cover dialogue, speaker identity, and significant non-speech audio. The Understanding document's own example of a sufficient human method is CART (Communication Access Realtime Translation) on a live web performance. ASR is faster to stand up and worse at names, numbers, and punctuation. Neither is an offline file.

Offline captions start from a finished soundtrack. You can pause, rewind, and run forced alignment against a corrected transcript. You can add speaker labels and non-speech cues that the live pass never had time to write. You can read the file against the picture for placement. The FCC's quality rule in § 79.1(j)(2) is written for this world even though it is a television rule, not a web rule: accuracy (verbatim in the original language, including lyrics when they are on the audio, proper spelling, punctuation, speaker identity, music and sound effects), synchronicity, completeness from start to end, and placement that does not cover essential visuals.

§ 79.1(j)(3) then says the Commission will take extra factors into account when applying those standards to live and near-live programming: overall understandability, delay "to the extent technically feasible," captions getting cut off at commercial breaks, and the programme's susceptibility to blocking. That is the regulator stating, in print, that live is graded differently. It is not a license to skip captions. It is a warning not to grade a live overlay as if it were an offline file.

The same regulation's best-practices section (§ 79.1(k)(1)(ii)(C)) sets a presumption that prerecorded programmes will be captioned offline before air, with a list of commercially reasonable exceptions (delivery too close to air, late delivery, technical problems with the caption file, last-minute editorial changes, confidentiality, networks that run real-time captioning on everything because breaking news can interrupt). If your "live captions" are sitting on a file that has been in the library for a week, you are in the prerecorded bucket whether or not the overlay was produced by a live engine.

When live is acceptable

Live is the right product when the alternative is no captions until tomorrow, and tomorrow is after the event.

• Earnings calls, webinars, town halls, and live launches, watched as they happen.
• Breaking or near-live news, where SC 1.2.2's own Understanding text admits the author may have to choose between delaying the information and publishing it inaccessible for an interval.
• Any stream whose editorial content can still change after "start."

Acceptable does not mean unexamined. A live pass still has to be a caption: speaker identity when it matters, significant non-speech audio, and a delay small enough that the words still attach to the person talking. What you do not do is promise the same verbatim quality you would sign off on a recorded tutorial.

If the session is recorded and the recording is the thing people will watch next month, the live overlay is a day-of accessibility measure, not the deliverable. Plan an offline recaption of the VOD. The live file can stay on the live page.

When offline is required

Offline is the right product when the file will be replayed, searched, translated, or used as training.

• Evergreen product videos, onboarding, and help centre clips.
• Ads, explainers, and anything a buyer will sit with.
• Course libraries, conference VODs, and "live" streams that were actually produced yesterday.

For those files, live ASR leftovers fail in boring, repeatable ways: missing punctuation that changes a claim, speaker labels that stick to the wrong person after a handoff, numbers that were guessed, and a clock that drifts early after the first two minutes because segment timestamps and window rounding accumulate. None of those are live-only bugs. They are what you get when a live engine is left on a file that could have been checked.

Versely's own caption path is an offline path. Add captions to a video transcribes and burns styled cues into a finished clip. Get a video transcript returns the words as text so you can correct them before anyone sees a cue. Both assume the soundtrack already exists. There is no live-caption product in that pipeline, and there should not be: a generator that has to wait for a file is not a stenographer.

Spot-check method: live

You cannot WER a live stream against a reference that does not exist yet. You can still fail it in ten minutes.

1. Open (first two minutes). Confirm captions appear at all. Note the lag by ear: if the caption for a sentence arrives after the next sentence has started, speaker identity is already compromised.
2. Names and numbers. Write down three proper nouns and three figures you hear. Check the overlay. Live ASR loses these first.
3. Handoff. When a second speaker starts, check whether the label (or a visual cue in the caption) changes. A sticky name is a live defect even if the words are right.
4. Non-speech. A door slam, an alarm, a laugh that is doing narrative work. WCAG's definition of captions includes those. A dialogue-only overlay is incomplete.
5. The join. If the event dumps to VOD automatically, watch the first minute of the recording. Live buffers get concatenated wrong. That minute is where "we captioned the live" quietly becomes "the VOD has no captions."

Log the show, the timestamp, the error class (lag, name, number, speaker, non-speech, missing), and whether you would still ship the VOD with this overlay. If the answer is no, the offline recaption is part of the event rundown, not a nice-to-have.

Spot-check method: offline

Offline gets a numeric pass plus a completeness pass. The numeric pass is word error rate against a reference transcript, which is a different article's recipe. The completeness pass is the one live QC cannot do, because the file now has a beginning and an end.

1. Start and end. Cue 1 is on the first audible speech, not the first word the engine was confident about. The last cue covers the last audible speech, not the last full sentence the model emitted. § 79.1(j)(2)(iii) calls this completeness: captions run from the beginning to the end of the programme to the fullest extent possible.
2. A mid-file window, not the hook. Open a 30-second window around the midpoint and a window around the last spoken line. Live-quality ASR that was "good enough" at 0:20 is where drift shows.
3. Speaker and non-speech, on purpose. A word-perfect track that never names who is talking, and never marks a meaningful sound, fails WCAG's own definition of captions even at WER 0. Score those as separate error classes, not as "style."
4. Placement against the picture. Full-screen burned-in captions that cover a face, a price, or a graphic fail § 79.1(j)(2)(iv) and WCAG's note that captions should not obscure relevant video information. Pause on a busy frame, not on a wide shot.

For a single clip this is a 15-minute sit. For a library, do not watch every file. Sample. The next post in this craft is the sampling method. For today: never let the live overlay stand in for that sample on a file that will be replayed.

A practical split on one event:

• Day-of: live captions on the stream (human CART if the audience is paying to follow every figure; ASR if the alternative is nothing).
• Next working day: speech-to-text on the recording, human pass on names and numbers, then the caption generator or the transcribe-and-caption path for the VOD.

Two products. Two checks. One of them is allowed to be late. The other is not allowed to be the recording.

FAQ

Can I leave live ASR on the VOD if it "looked fine"?

Not if the recording is the lasting copy. "Looked fine" is a live judgement made at the open. Offline QC is a start-to-end judgement against a file that will be replayed. Recaption the VOD, or at least sample it. Do not copy the live overlay forward by default.

Does WCAG require live captions on a two-person call inside our app?

SC 1.2.4 says it was intended for broadcast of synchronized media, not to require that two-way calls through a web app be captioned regardless of the users' needs. Responsibility, when it exists, sits with the content providers (the callers) or the host caller, not automatically with the application. A produced webinar is not that exemption.

Is near-live the same as live for QC?

For television, the FCC defines near-live as recorded less than 24 hours before first air and then grades live and near-live with the same extra factors. For a web library, treat anything you can pause and recaption as offline. The 24-hour window is a broadcast constraint, not a reason to skip a transcript pass on a file sitting on disk.

Do burned-in live captions help the VOD?

They help the people watching now, and they survive a re-upload. They also freeze every live error into pixels, which is the opposite of what you want on an evergreen file. Prefer a closed (toggleable) live overlay on the stream, then an offline file on the recording.