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

Source: https://complymetric.com/blog/2026-10-11-accessibility-statements-that-mean-something.html

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.

## Get a free accessibility scan of your website

[Free accessibility scan](mailto:hello@complymetric.com?subject=Free%20accessibility%20scan%20-%20complymetric.com)