CaptionPass, evaluated against WCAG 2.1 Level A and AA · audit run 23 August 2026
We sell conformance evidence. Publishing a flattering claim about our own accessibility would disprove the product in a sentence, so this report was written after the audit ran and says what the audit found — including 0 criteria we fail.
Almost nothing here says Supports. That is the same rule we apply to a customer's captions: a criterion that can be disproved by the audit but never proved by it does not get rounded up because the scan came back clean.
A repeatable static audit of every JSX file in the application, checking what source can settle: missing text alternatives, interactive elements with no focus style, unlabelled inputs, positive tabindex, buttons that submit unexpectedly, and click handlers no keyboard can reach. It cannot see rendered colour contrast, real focus order, screen-reader output, or whether an accessible name is useful — those need a browser and a person, and no criterion below is marked Supports on the strength of the scan alone.
The audit is a script in the repository and is re-run on every change, so this page can be reproduced rather than taken on trust.
| Criterion | Level | Remarks |
|---|---|---|
| 1.1.1Non-text contentLevel A | Partially Supports | No image in the application is missing a text alternative. Whether each alternative describes its image usefully has not been reviewed by a person, so this is not claimed as met. |
| 1.2.2Captions (prerecorded)Level A | Supports | The product ships no prerecorded audio or video of its own. There is nothing to caption, and this is the one row where a clean answer is the whole answer rather than the limit of what was checked. |
| 2.1.1KeyboardLevel A | Partially Supports | Two controls were reachable only with a mouse when the audit ran — a cue row in the console and a shortcuts dialog with no Escape handling — and both were fixed before this report was published. No click handler now lacks a keyboard path. Whether every keyboard path is sensible in practice needs a person driving the app. |
| 2.4.3Focus orderLevel A | Partially Supports | No element forces a positive tabindex, which is the failure source can see. The actual reading order of a rendered page has not been walked by a person. |
| 2.4.7Focus visibleLevel AA | Partially Supports | Every interactive element that removes the browser's default outline provides a replacement focus style. Whether each replacement has adequate contrast against its background needs a rendered page and has not been measured. |
| 3.2.2On inputLevel A | Partially Supports | No button inside a form relies on the implicit submit type, so no control fires a form when a plain click was intended. Other kinds of unexpected change of context have not been reviewed. |
| 3.3.2Labels or instructionsLevel A | Partially Supports | Every form control in the application now has an accessible name — a wrapping <label>, an id, or an aria-label. This was the one criterion this report published as Does Not Support, and the 18 controls that genuinely lacked a name have been fixed. Whether each name reads usefully to somebody using a screen reader has not been reviewed by a person, so this is not claimed as met. |
| 1.4.3Contrast (minimum)Level AA | Not Evaluated | Colour contrast cannot be established from source. It needs the rendered page in both themes, and no such measurement has been made. Reported as not evaluated rather than assumed either way. |
| 4.1.2Name, role, valueLevel A | Not Evaluated | Whether every control exposes a correct name, role and value to assistive technology needs a screen reader and a person. Parts of it overlap with 3.3.2 above, which is already failing. |
A report that names a defect and says nothing about fixing it is half a document.
2.1.1 — Fixed before this report was first published. Cue rows are now buttons with a keyboard activation path, and the shortcuts dialog closes on Escape with a real control for its backdrop.
3.3.2 — All 18 genuinely unnamed controls now have one: the cue console time and text fields, the project search and rename boxes, every file picker, the command palette, and six filters in the operator console. Done in the same change that corrected the count.
1.4.3 / 4.1.2 — Contrast, focus order and assistive-technology output are the criteria a source scan can never reach. Until somebody sits with the app, they stay marked not evaluated here.
The first version of this report said 79 form controls had no accessible name. The real number was 18.
The audit only accepted an id, an aria-label or an aria-labelledby. It missed controls wrapped in a <label>, which is valid implicit association and arguably the better pattern; it also counted two spam honeypots that are aria-hidden by design and one shared primitive that takes its name from whoever renders it. The rule was corrected, and the 18 genuine cases were fixed rather than argued with.
2026-08-23
If you hit something this report does not mention, that is a gap in the audit as much as in the product, and we want both. Write to support@captionpass.com.
The conformance reports we generate for customers — across their caption libraries — are described on the compliance page.