The accessibility statement has to be true. That is the hard part.

Generating the document takes ten minutes and there are free tools for it, including an official one. The requirement that costs work is buried in the middle: the declaration must be accurate, and based on an evaluation you actually did.

Two different obligations, routinely confused

People say "accessibility statement" about two separate things. Getting them mixed up leads to publishing the wrong document under the wrong rules.

Public sector statementEAA accessibility information
Comes from Directive (EU) 2016/2102, the Web Accessibility Directive Directive (EU) 2019/882, the European Accessibility Act
Who Public sector bodies Providers of covered services to EU consumers
Form A prescribed model — Commission Implementing Decision (EU) 2018/1523 Information about how the service meets the requirements; no single EU-wide template
Enforcement National monitoring bodies, with a complaints procedure National market surveillance and service authorities

The rest of this page is about the first one, because it is the one with a prescribed shape. If you are a private company under the EAA, the model is still the best available guide to what a reader expects to find.

What the model statement contains

The model in Decision 2018/1523 is short, and every part of it is there for a reason:

Notice what dominates that list. Four of the six items are about what is wrong and what the user can do about it. The statement is not a badge. It is a disclosure document, and it is designed to be most useful when the answer is "partially compliant".

The requirement generators cannot satisfy for you

Decision 2018/1523 does not only prescribe the shape. It requires that the declarations about compliance

… are accurate and based on … an actual evaluation of the website's or mobile application's compliance with the requirements.

So a statement is not a formality you generate and publish. It is a claim about your product, and the law asks what the claim rests on.

The failure mode is specific and common: a generator asks a few questions, you pick "fully compliant" because nothing obviously looks broken, and you publish a claim you have never tested. That statement is worse than no statement — it is a documented, dated, public assertion that is not true, made by the organisation it is about.

"Partially compliant", with an honest list of what fails and a date for fixing it, is a normal and respectable answer. It is what the model was built to express.

What counts as an actual evaluation

For anything on the web, the substance is EN 301 549, whose web chapter adopts WCAG Level A and AA. An evaluation means going through those success criteria against your product and recording what you found — which is the same exercise as filling in an accessibility conformance report, done for a different audience.

Automated scanning is a part of it and not the whole. axe-core detects around 57% of issues by volume and roughly a third of the success criteria; the ones that fail most often in real audits — info and relationships, name/role/value, focus visibility, keyboard operation — are largely the ones no scanner can judge. A statement whose stated evaluation method is "we ran a scanner" is disclosing that too.

An overlay does not change your compliance status. It changes what a visitor sees, not what an evaluation finds, and a statement that credits one is claiming something the underlying pages do not support.

Keeping it true afterwards

The statement carries a date because it is expected to go stale. A product ships, a component changes, and the document on your site still describes last year's build. The model asks for a review date for exactly this reason, and reviewing it is cheaper than the alternative: the statement is the one place where an organisation writes down, publicly and under its own name, what it believes about its own accessibility.