Guides › How to write an accessibility statement that holds up

How to write an accessibility statement that holds up

8 min read Reviewed 2026-08-22

An accessibility statement is the one piece of compliance evidence a regulator, a procurement team or an irritated customer will look for first. It is also the easiest to get wrong in a way that makes your position worse than saying nothing.

Why it matters

Under the EAA, service providers are expected to make information available about how their service meets the accessibility requirements. The accessibility statement is how that expectation is met in practice, following the pattern already well established in the public sector under the Web Accessibility Directive.

Three audiences read it, and they want different things:

• Users want to know whether they can complete a task, and who to tell when they cannot.
• Procurement teams want a conformance claim they can put in a supplier file. An unanswerable accessibility question in a tender is a lost deal.
• Regulators want evidence you understand your obligations and are managing them. A dated, specific, honest statement is exactly that evidence.

What it must contain

1. Scope. Which website, app or service this covers. Be precise — subdomains and native apps are separate things.
2. The standard. Name it: WCAG 2.1 Level AA, via EN 301 549.
3. Your conformance claim. Full, partial, or non-conformant. See below.
4. Known issues. A specific list of what does not conform, in language a user can understand, with the reason where relevant.
5. Remediation timeline. When you expect each item to be fixed. Realistic dates.
6. Any disproportionate burden claim, with the reasoning, if you are relying on one.
7. Feedback mechanism. An email address and ideally a phone number, monitored by a person, with a stated response time.
8. Escalation route. What a user can do if you do not respond adequately — the relevant national enforcement body.
9. Assessment method and date. Self-assessment or third-party audit, and when it was carried out.

Choosing your conformance claim

Three options, and most organisations should pick the middle one:

• Fully conformant — every criterion met, everywhere, verified. Almost nobody can honestly say this about a site of any size, and an overclaim that a complainant disproves in five minutes is materially worse than an honest partial claim.
• Partially conformant — you meet the standard except for the specific, listed issues. This is the right answer for the overwhelming majority of organisations. It is honest, it demonstrates active management, and it is a defensible position.
• Non-conformant — significant parts do not meet the standard. Uncomfortable to publish, but paired with a credible plan and dates it still beats silence.

Four mistakes that create liability

1. Claiming full conformance you cannot evidence

If a complainant demonstrates a Level A failure on your checkout the day after you published a claim of full conformance, you have handed them evidence that your compliance documentation is unreliable. Partial conformance costs you nothing and protects you.

2. Relying on an overlay widget as the claim

Accessibility overlays — the scripts that add a floating accessibility button — do not remediate underlying code and are widely rejected by disability advocacy organisations and accessibility practitioners. Litigation in other jurisdictions has proceeded against sites that had one installed. Fix the code. An overlay in place of remediation is a purchased liability.

3. A feedback address nobody monitors

The feedback mechanism is not decorative. An unanswered accessibility complaint is often the precise step that turns a fixable problem into a formal one. Route it somewhere a human reads.

4. Letting it go stale

A statement dated three years ago, listing issues you fixed two years ago, tells a reader that nobody here is paying attention. It is worse than no statement, because it is evidence of neglect rather than absence.

Keeping it current

• Review at least annually, and after any significant redesign.
• Update the known-issues list as you fix things — deleting a resolved item is a good day.
• Re-audit before each review so the claim rests on current evidence, not a memory.
• Keep the superseded versions. A trail of dated statements showing steady improvement is genuinely persuasive.

Generate a structured statement from your audit results →

Last reviewed 2026-08-22. General information, not legal advice.