A statement must list known failures, not only claim overall compliance

What it is

Writing only “we conform to such-and-such a standard,” while hiding the keyboard trap still being fixed and the course videos still without captions, helps marketing, not the person trying to finish a task. Listing known accessibility issues means writing the failures as a list: which task, which barrier, whether there is a workaround, when it is planned to be handled. Templates such as GOV.UK and EN 301 549 treat “what is not accessible, and why” as the body, not a footnote. Overall conformance can be a conclusion; a conclusion with no list is advertising.

Why it happens

Readers of the statement include people who have a task to finish, regulators, and later auditors. They need residual risk, not a slogan. The second layer is that a list constrains the organisation: a published failure now has a public date, and an unfixed item will have to be explained; a failure left off the list becomes evidence of dishonesty the moment a user hits it. An honest statement would rather be short and spread the gaps on the table than use “mostly conforms” to smooth over a failed conjunction. Score-like “almost passing” is a different problem; this card asks whether the document hands known gaps to the reader.

Studying it

Score public statements against a template (government model statements, EN 301 549 statement elements): are specific failures listed, are alternatives named, is there a time horizon. Walk the same site with keyboard and a screen reader, and see how many of those failures the statement names.

Independent variables: statement type (slogan only / failures with no alternative / failures plus alternative plus date). Dependent variables: share of actual failures named; whether a reader can change path from the list; whether failures found after the statement date were added.

Do not let a scan total stand in for “is the list complete.”

Where it stops holding

Security holes and unpublished fraud checks do not belong in an accessibility statement; confidential exceptions unrelated to a channel use another disclosure route. Internal pre-release environments can have no public statement; once the URL is public, the list duty starts. When failures are numerous enough to read like a manual, cluster them by task (checkout, player, upload); do not paste a scanner CSV. Listing a failure is not the same as holding partial-conformance legal status — scope and conjunction still follow the conformance rules; the statement only hands residual risk to the reader.

Applying it

• Give the statement a “currently not accessible” section. Each item names the task or page, the phenomenon, the known cause, an alternative (phone, human, another format), and a target date.
• Do not keep “we are committed to accessibility” with no failure items. If there are genuinely zero known failures, name the scope of the last full check, rather than a still emptier slogan.
• Reconcile the product defect queue with the public list. When a published failure closes, remove it from the list and keep a change record.
• How to check: read the whole statement with a screen reader and count list items. Then walk checkout and the player from the keyboard, and match failures against the list. In the product but not on the list: add it before republishing. On the list with no alternative: add one, or mark “no alternative.”

Related

• Same group: J1.12.2 A statement must offer a channel for reporting newly found barriers · J1.12.3 A statement must name test methods and the last update date · J1.12.4 Conformance documents are useless unless they are themselves accessible
• Nearby: J1.10 Scope of Conformance Claims · J1.10.2 Passing almost every check is not overall conformance
• Search terms: known accessibility issues · accessibility statement · partial conformance