Accessibility Statements That Mean Something: What to Publish and What to Skip

2026-10-11

The boilerplate problem

Almost every large site has an accessibility statement, and almost all of them say the same nothing: we are committed to accessibility, we strive to meet WCAG, contact us with feedback. It is compliance theater. A statement that commits to nothing specific cannot be measured, and a statement that cannot be measured does not drive improvement.

The irony is that the statement is often the first thing a plaintiff's lawyer reads. A vague statement next to a site full of barriers reads as indifference. A specific, honest statement reads as good faith. Specificity is both the better engineering practice and the better legal posture.

What a useful statement contains

Start with the standard and the conformance target, stated plainly: this site aims to conform to WCAG 2.2 level AA. Name the version. Accessibility standards evolve, and a statement that does not name its target is not anchored to anything.

Then name the known gaps. This is the part everyone skips, and it is the most valuable section. A short list of known issues with remediation timelines, third-party content outside your control, legacy PDFs being replaced, a checkout flow mid-rebuild, tells users what to expect and tells your own team what is on the hook. Honesty about gaps is not an admission of liability. It is evidence of a process.

The feedback channel

Every statement needs a way to report a barrier, and that channel has to work. An email address that bounces, a form that is itself inaccessible, or a phone number nobody answers turns the statement into a lie. Test the feedback path the way you would test checkout: with a keyboard, with a screen reader, end to end.

Commit to a response time and keep it. Two business days is a reasonable promise. The reports that come in are free user testing from the people most affected by your barriers. Treat them that way.

What to skip

Skip the legal throat-clearing about striving and commitment. Skip claims of conformance you have not tested. Claiming full WCAG AA conformance without an audit is worse than saying nothing, because it is a specific claim that is probably false. If you have not audited, say the site is being evaluated and give the timeline.

Skip the accessibility widget badge as a substitute for real work. Overlays do not fix barriers and their presence on a statement page undermines the whole document. If the statement mentions an overlay as the accessibility solution, rewrite the statement and fix the site.

Keeping it alive

A statement is a living document. Date it, review it quarterly, and update it when the known-gaps list changes. Tie the review to your release cycle so it cannot drift. The best accessibility statements read like engineering status reports, because that is what they are: a public window into the work of making the site usable for everyone.

Frequently asked questions

What should an accessibility statement include?

The standard you target, the known gaps you are working on, and how to report a barrier and get help. A useful statement is honest about limitations. Boilerplate that claims perfection helps no one and hurts credibility.

Do accessibility statements reduce legal risk?

A good one helps demonstrate good faith, which matters in disputes. But a statement is not a shield: it does not fix an inaccessible checkout. Publish an honest statement and pair it with a real remediation program.

How often should the statement be updated?

Whenever your conformance changes: after major remediation, after replatforming, and at least annually. A statement describing a site you no longer run is worse than none, because it documents claims you cannot support.