Concepts

Accessibility statement

A public-facing document declaring an organisation's accessibility commitments, target conformance level, known gaps, and how to report barriers. Required by EAA Article 7, PSBAR, and most public-sector regimes.

An accessibility statement is a public-facing document declaring an organisation’s accessibility commitments, target conformance level, known gaps, and how to report barriers. It exists at a stable URL — typically /accessibility/ — that any visitor can find from any page.

Why it matters

Beyond being good editorial practice, accessibility statements are legally required under several major regimes:

  • EAA Article 7 requires services in scope of the European Accessibility Act to publish accessibility information meeting Annex V’s content requirements.
  • PSBAR (UK) requires every public-sector body’s website to publish a statement in a specific format defined by the Cabinet Office.
  • The EU Web Accessibility Directive has required public-sector accessibility statements across member states since 2018.
  • US Section 508 technically requires “documentation of accessibility features” with each federal procurement, typically satisfied by the VPAT/ACR plus a statement.

Even where no law mandates one, a statement is the operational doorway into the rest of an organisation’s accessibility programme — it’s where auditors, plaintiffs, and disabled users look first.

What a useful statement contains

A statement that actually works includes, at minimum:

  1. Target conformance level, named specifically. “We aim to conform to WCAG 2.2 Level AA” — not “we believe in accessibility.”
  2. Current status against that target — fully conformant, partially conformant, or “in progress.” Honesty here matters; courts have treated misleadingly optimistic statements as evidence against the defendant.
  3. Known issues with timelines for remediation. The W3C’s accessibility-statement generator gives a structure for this. Listing issues is not an admission of liability — it’s a documented commitment to fix them.
  4. A real human contact — email or form — with a stated response SLA (5 business days is the practical norm). Generic info@company.com addresses with no SLA are a red flag.
  5. A date of last review. Best practice is to review and update at least annually, more often when major features ship.
  6. Compatibility notes — which assistive technologies and browsers were tested.
  7. Legal information — the enforcement mechanism in the user’s jurisdiction (e.g., EAA Annex V requires linking to the relevant member-state complaint procedure).

Common failure patterns

  • The “we care” statement. A paragraph of warm words (“We are committed to providing an accessible experience to everyone”) with no conformance target, no contact, no specifics. Useless.
  • Out-of-date. Says “last reviewed 2019” — a six-year-old commitment to WCAG 2.0 AA on a product that has shipped half a dozen major rewrites since.
  • Hard to find. Stuck in a footer with low-contrast type or a legal-page roll-up. The link should be on every page, in a predictable location (footer is fine if it’s visible).
  • Buried contact form. A statement that lists no email and routes the user to a 12-field contact form to report a barrier shifts the cost of reporting onto the user.

The W3C’s generator

The W3C’s accessibility-statement generator (www.w3.org/WAI/planning/statements/generator/) produces a template that hits all the required EAA / EU WAD / PSBAR fields. It’s a good starting point. The mistake to avoid is leaving the placeholder text intact and publishing the template verbatim.