Accessibility statements: what a credible one contains, and how to tell if yours is good

An accessibility statement is one of the four things the EAA requires, alongside technical conformance, active governance, and documentary evidence. It is also the one most likely to be read by the people who can act on it, for a simple reason: it is public, and it takes about thirty seconds to assess. An enforcement body or an enterprise procurement team can read it without asking you for anything.

That is exactly why a vague one is a liability rather than a placeholder. A statement is not marketing copy. It is meant to be the visible summary of an actual evaluation, and the absence of any specifics is a fairly reliable signal that no real evaluation happened.

Why most organisations don't have a good one

Most accessibility statements read like a values page: a line about commitment, a mention of "striving to meet WCAG", an email address for accessibility concerns. It looks reasonable, and it says almost nothing. There is no date, no version, no scope, no evidence of testing. It is the version that gets written before anyone has evaluated the product, and it is the version that does not hold up when someone checks.

What a credible statement contains

This is no longer a matter of opinion. WCAG-EM 2.0, the W3C's accessibility evaluation methodology published in July 2026, sets out exactly what a credible evaluation statement contains. Six things:

1. A date. When the evaluation was made. A statement with no date is stale by default, because a product changes and an undated claim cannot be trusted against the current version.
2. The WCAG version and conformance level. For example, WCAG 2.1 Level AA, the level the EAA's harmonised standard works to. "We follow accessibility best practices" is not a claim; it is an evasion of one.
3. What the statement covers. A clear definition of the product or service, and its scope. "Our digital services" is a hand-wave. A credible statement names the site, app, or journeys it applies to.
4. The technologies relied upon. What the product is built with and assumes, so that the conformance claim can be understood in context.
5. The accessibility-support baseline. The assistive technologies and browsers the product was actually tested against. A claim of conformance means little without saying what it was tested with.
6. Where it does not fully conform, and why. Partial-conformance disclosures: the specific areas that do not yet meet the standard, and the reason.

The tell: a good statement names its own gaps

That last item is the one that separates a real statement from a written wish. A statement that names its own gaps, honestly and specifically, is the sign of an evaluation that actually took place. A statement that implies everything is fine, with nothing specific behind it, is the one that raises questions rather than settling them.

There is a deeper reason for this, and it is worth understanding. The same methodology is explicit that evaluating a representative sample of a product does not permit a conformance claim for the whole product, because unfound errors always remain possible on the parts that were not tested. So a statement that claims blanket, fully-compliant conformance off a light check is not describing something the methodology supports. Honest scope is not caution. It is what a credible statement is made of.

How to tell if yours is good

Read your own statement against the six items above. If it has a date, a specific version and level, a defined scope, the technologies and assistive technologies it was tested with, and a plain account of where it falls short, it is doing its job. If it has a paragraph of commitment and an email address, it is not a statement in the sense the EAA means, and it will not help you if the question ever gets asked in earnest.

The gap between the two is not a writing problem. It is the difference between a statement that is backed by an evaluation and one that is not.