Your Accessibility Statement Is a Metric Too: What a Credible One Contains

2026-10-17

Every accessibility program eventually publishes a statement, and most statements are useless. They promise commitment in warm language, claim conformance without a level, and offer an email address that routes to a general inbox where barrier reports go to die. Auditors know the genre on sight, and so do the disabled customers the statement is supposedly for.

A good statement is short, specific, and a little uncomfortable, because it reports a real status instead of performing one. It is also measurable: its contents are a checklist, and most published statements fail half of it.

Name the target and the honest status

State the standard precisely: WCAG version and level, and the conformance actually achieved, fully, partially, or not yet, per page or product area if it varies. Partially conformant, with the non conforming parts named, is a credible sentence. Fully accessible, with no standard cited, is not.

Honesty here is protective, not risky. A statement that admits known gaps and a plan to fix them demonstrates the good faith that regulators and enterprise customers look for. A blanket claim contradicted by one keyboard test demonstrates something else, in writing, on your own site.

A contact route that reaches a human

The statement must offer a way to report barriers that itself is accessible and actually monitored: a named inbox or form, an alternative to any phone only option, and a stated response time. Barrier reports are free audits delivered by the people your program exists to serve; routing them nowhere is the commonest unforced error in this space.

Track what arrives. Volume and type of reports belong in program metrics, because they measure what your internal testing missed, which is the most valuable information in any accessibility program.

Date it, own it, update it

An undated statement is a statement nobody maintains. Put the publication and last review dates on it, name the owning team or role, and update it when audits complete, when major gaps close, and when new ones are found. The review cadence itself signals whether the program behind the statement is alive.

Version the statement alongside your conformance reports so the three documents tell one consistent story. Procurement teams compare them. A statement claiming progress that the latest audit contradicts undermines both documents and the vendor evaluation with them.

What to leave out

Skip the paragraphs of commitment rhetoric; one sentence of intent is enough. Skip legal threats or burdensome proof demands aimed at people reporting barriers. And skip claiming that an overlay or a plugin has made the site compliant, a claim that has drawn regulatory attention in its own right and satisfies no informed reviewer.

The statement's job is information: status, gaps, contact, dates. Every sentence that is not information is decoration that dilutes the sentences that are.

Frequently asked questions

What must an accessibility statement include?

The standard and level targeted, the honest conformance status with known gaps, an accessible and monitored contact method for reporting barriers, and publication and review dates with a named owner.

Is admitting gaps in the statement risky?

Less risky than the alternative. Documented honesty with a remediation plan reads as good faith to regulators and customers, while a blanket full compliance claim that testing contradicts is a written liability.

How often should the statement be updated?

At least at each audit cycle and whenever major gaps open or close. The last review date on the statement is itself a signal reviewers use to judge whether the program is active.

Does an overlay make a statement claim valid?

No. Claiming conformance on the basis of an overlay widget is not substantiated by the tool and has itself attracted complaints and regulatory scrutiny. The statement must reflect the underlying site's actual status.