# CaptionPass — full reference

> Expanded companion to https://www.captionpass.com/llms.txt. Every standard CaptionPass grades against, clause by clause, with what each clause requires and exactly where a caption file stops being sufficient evidence.

Generated from the engine's own standard catalogue on every request. If a clause is listed here, the engine evaluates it; if it is marked not checkable, the engine reports it as not evaluated and never as a pass.

## Coverage vocabulary

- checked — the caption file is sufficient to settle this clause. A pass is a real pass.
- partial — the file can demonstrate a failure but cannot demonstrate a pass. No findings means nothing detectable is wrong, which is a weaker statement than the clause being met.
- not_checkable — settling this needs the audio, the player, or a human. Always reported as not evaluated.

## WCAG 2.1 Level AA

- Identifier: `wcag-2.1-aa` (the value the v1 API accepts in the `standard` field)
- Citation: W3C Web Content Accessibility Guidelines 2.1, Level AA (W3C Recommendation, 5 June 2018)
- Source: https://www.w3.org/TR/WCAG21/
- Applies to: The technical standard named by the ADA Title II web rule for state and local government content, due 26 April 2027 for large entities and 26 April 2028 for small ones.
- Completeness pack in scope: yes

### 1.2.2 — Captions (Prerecorded)

- Coverage: partial
- Requirement: Captions are provided for all prerecorded audio content in synchronized media.
- Diagnostic codes: no_cues, empty_input, late_caption_start, caption_gap, coverage_low
- Limitation: A caption file proves captions exist, and can show they start late or skip stretches of the programme. It cannot prove they cover all audio, because that comparison needs the audio.

### 1.2.4 — Captions (Live)

- Coverage: not_checkable
- Requirement: Captions are provided for all live audio content in synchronized media.
- Limitation: Live captioning is a property of the broadcast, not of a delivered file. Nothing in a sidecar can settle it.

## EN 301 549 (European accessibility)

- Identifier: `en-301-549` (the value the v1 API accepts in the `standard` field)
- Citation: ETSI EN 301 549 V3.2.1 (2021-03), Accessibility requirements for ICT products and services
- Source: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/
- Applies to: The harmonised European standard behind the European Accessibility Act, in force since 28 June 2025, and behind EU public-sector procurement.
- Completeness pack in scope: yes

### 9.1.2.2 — Captions (Prerecorded)

- Coverage: partial
- Requirement: Web content shall satisfy WCAG 2.1 success criterion 1.2.2 — captions for all prerecorded audio in synchronized media.
- Diagnostic codes: no_cues, empty_input, late_caption_start, caption_gap, coverage_low
- Limitation: A caption file proves captions exist, and can show they start late or skip stretches of the programme. It cannot prove they cover all audio, because that comparison needs the audio.

### 7.1.2 — Captioning synchronization

- Coverage: partial
- Requirement: Where ICT displays captions, it shall preserve synchronization between the audio and the corresponding captions.
- Diagnostic codes: overlapping_cues, negative_duration, zero_duration, invalid_timestamp, cue_too_short, cue_too_long
- Limitation: The timeline can be checked for internal consistency — ordering, overlap, plausible durations. Whether a cue lands on the word being spoken needs the audio.

### 7.1.3 — Preservation of captioning

- Coverage: checked
- Requirement: ICT that transmits, converts or records video with captions shall preserve the caption data so it can be displayed as intended.
- Diagnostic codes: text_altered, empty_cues_dropped, truncated_block, split_not_possible

## FCC caption quality (47 CFR 79.1)

- Identifier: `fcc-79.1` (the value the v1 API accepts in the `standard` field)
- Citation: 47 CFR 79.1(j)(2) — caption quality standards, adopted by FCC 14-12 (2014)
- Source: https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-79/subpart-A/section-79.1
- Applies to: Video programming distributed on US television, and — through 47 CFR 79.4 — clips of that programming redistributed online.
- Completeness pack in scope: yes

### 79.1(j)(2)(i) — Accuracy

- Coverage: not_checkable
- Requirement: Captioning shall match the spoken words in their original language, and convey background noises and other sounds, to the greatest extent possible.
- Limitation: Deciding whether the words are right means comparing them to the audio. This engine never sees the audio and will not assert accuracy from the text alone.

### 79.1(j)(2)(ii) — Synchronicity

- Coverage: partial
- Requirement: Captioning shall coincide with the corresponding spoken words and sounds, and be displayed at a speed that can be read by viewers.
- Diagnostic codes: reading_speed_high, cue_too_short, cue_too_long, overlapping_cues, negative_duration, zero_duration
- Limitation: Readable speed is fully decidable from the file. Coinciding with the spoken word is not — that half needs the audio.

### 79.1(j)(2)(iii) — Completeness

- Coverage: partial
- Requirement: Captioning shall run from the beginning to the end of the programme, to the fullest extent possible.
- Diagnostic codes: late_caption_start, caption_gap, coverage_low, no_cues
- Limitation: Gaps and a late start are arithmetic. Whether a stretch with no captions was silence or dropped dialogue needs the audio, and coverage against programme length needs a known duration.

### 79.1(j)(2)(iv) — Placement

- Coverage: partial
- Requirement: Captioning shall not block other important on-screen information, and shall not run off the edge of the video screen.
- Diagnostic codes: too_many_lines, vtt_cue_settings_dropped, ttml_styling_ignored
- Limitation: Line count and dropped positioning are visible in the file. Whether a caption covers a lower third or a scoreboard needs the video.

## DCMP Captioning Key (educational media)

- Identifier: `dcmp` (the value the v1 API accepts in the `standard` field)
- Citation: Described and Captioned Media Program, Captioning Key: Guidelines and Preferred Techniques
- Source: https://dcmp.org/learn/captioningkey
- Applies to: Educational media, and the house style most US school and university media libraries are procured against.
- Completeness pack in scope: yes

### presentation-rate — Presentation rate

- Coverage: checked
- Requirement: Captions are presented at a rate the intended audience can read, slower for younger viewers than for adults.
- Diagnostic codes: reading_speed_high
- Limitation: Enforced at the adult rate. DCMP grades the rate by audience and publishes it in words per minute; the cap here is that figure converted at five characters per word. A younger audience needs a lower cap set explicitly.

### line-treatment — Line length and count

- Coverage: checked
- Requirement: Captions are limited to two lines, broken at logical points rather than by width alone.
- Diagnostic codes: too_many_lines

### speaker-identification — Speaker identification

- Coverage: partial
- Requirement: Speaker changes are identified so the viewer can tell who is speaking.
- Diagnostic codes: missing_speaker_label
- Limitation: A half-applied convention is detectable. Whether an unlabelled cue needed a label depends on who was speaking, which needs the audio.

### sound-effects — Non-speech information

- Coverage: partial
- Requirement: Sounds essential to understanding are described, in square brackets, distinct from dialogue.
- Diagnostic codes: non_speech_unbracketed
- Limitation: The convention is checkable wherever a description is present. Whether a sound was missed entirely needs the audio.

## Verifying a receipt

A conformance receipt carries per-clause verdicts, cue-level evidence, pinned engine versions, and an HMAC signature over its canonical JSON. Verification returns a distinct answer for each way a receipt can fail to be genuine — valid, tampered, unknown key, malformed, and so on — rather than a single true/false.

A receipt can be verified by anyone holding it, whether or not CaptionPass stored a copy: POST it to https://www.captionpass.com/api/verify-receipt, or paste it at https://www.captionpass.com/verify. A receipt we have no record of still verifies, which is the point of signing it rather than looking it up.

Worked example, generated through the production engine rather than seeded: https://www.captionpass.com/compliance/sample-receipt

## Contact

- Support: support@captionpass.com
- Enterprise: enterprise@captionpass.com
- Index version of this file: https://www.captionpass.com/llms.txt