What an accessibility statement needs to say
An accessibility statement is the only accessibility artifact most of your users, clients, and regulators will ever read. The code either works with a screen reader or it does not, but the statement is where an organization says, in public, what it did and did not achieve. Written honestly, it is both a legal document and a trust signal. Written as marketing, it is evidence against you. Here is what it needs to contain, and how to keep it truthful.
Who is required to publish one
In the EU, public sector bodies have been required to publish accessibility statements since the Web Accessibility Directive, in a mandated format. The European Accessibility Act extends documentation duties to in-scope private services: providers must explain, in their general terms or an equivalent public document, how the service meets the accessibility requirements. In the UK, public sector rules require a statement in a specified model. In North America there is no universal statement mandate, but statements are standard practice for organizations taking the ADA or AODA seriously, and they are routinely requested in procurement.
Even where not strictly required, a statement is worth publishing: it is where a user who hits a barrier finds the way to report it, which is far better for everyone than the alternative channels (a complaint to an authority, or a lawsuit).
The required contents
Across the EU model statement, the UK model, and W3C's guidance, the same core sections recur. A complete statement includes:
1. Scope. Which website or app the statement covers, precisely. One statement per distinct product is cleaner than one vague statement for everything.
2. Conformance status against a named standard. Name the standard and version (WCAG 2.1 AA, or EN 301 549 where the European legal context applies) and one of three honest statuses: fully conformant, partially conformant (the common, honest answer), or not conformant.
3. Non-accessible content. The heart of the document. List the known failures, in plain language, with the affected functionality: "Order history tables are not announced correctly by screen readers." For each, state either the planned fix or the reason it is exempt (for example, disproportionate burden, where the law allows that claim and you can substantiate it).
4. Preparation method and date. When the statement was prepared or last reviewed, and how the site was evaluated: self-evaluation, third-party audit, or tool-assisted review. Naming the method is required in the EU model; naming the actual evidence makes it credible.
5. Feedback channel. A working way to report barriers, with a stated response time, and someone actually answering. This is the most user-relevant section and the most commonly broken.
6. Enforcement route. In the EU and UK models, a link to the body a user can escalate to if the feedback channel fails them.
The mistakes that discredit a statement
- The perfection claim. "Fully conformant" on a site with visible failures tells every knowledgeable reader the statement is decorative. Partially conformant with a specific list reads as competence, not weakness.
- The stale date. A statement prepared three years ago describes a site that no longer exists. Review at least annually, and after significant releases.
- The evidence-free assertion. "We are committed to accessibility" with no method, date, or findings is a value statement, not an accessibility statement.
- The overlay disclaimer. A statement pointing at a widget as the accessibility strategy invites exactly the scrutiny described in our analysis of why overlays do not equal compliance.
- The dead feedback address. Test your own channel quarterly. A bounced email in a regulator's inbox is a bad artifact.
Keeping it truthful over time
The difficult part of a statement is not writing it; it is that its claims decay. Every release can silently change the conformance status, the known-issues list, and the "last reviewed" honesty. The only sustainable approach ties the statement to live audit data:
- Audit the real user journeys, including authenticated ones, on a cadence.
- Maintain the issue list per site with statuses, so "known limitations" is a query, not a memory exercise.
- Regenerate the statement from that data whenever the facts change.
This is how Complaudax treats statements: the product generates them, in the structures the EU, UK, Canadian, and US contexts expect, from the site's actual audit history, current issue list, and manual checklist state. The known-limitations section writes itself from open issues, and the evaluation method section cites real dates and engine versions. We use the same pipeline for our own statement, and every plan on the pricing page includes it.
One closing principle covers every section: write the statement you would be comfortable defending in front of the user who reported the barrier. Honesty in this document costs a little pride and buys a great deal of protection.