axessia.eu

Which documents do you need for an accessibility statement?

An overview of the documents that accompany an accessibility statement, and why the underlying assessment is the component that matters most.

An accessibility statement is not a standalone form that you fill in and publish once. It is the visible head of a small file. It should contain at least four documents: the statement itself with the scope and the level at which it is assessed, the underlying assessment with the findings, an improvement plan with priorities and deadlines, and where applicable the format that the supervisory authority in your country requires.

The detail that matters most on this topic is contained in that second document. The regulation does not ask for text stating that your site is accessible, but for verifiability: what is that conclusion based on, what has been tested, what explicitly has not, and what is being done about what does not yet comply. A statement without that substantiation is essentially a claim without proof, and that is precisely what supervisory authorities look at when they ask further questions.

The statement itself

The statement describes which part of your website or app falls under the assessment, which standard serves as the basis (EN 301 549, in practice WCAG 2.1 at level AA), and which components do not yet comply at the time of publication. It also contains a way for visitors to report an accessibility issue, and the date of the last assessment. The latter is more than a formality: a statement that is two years old while the site has since been redesigned three times no longer tells you what is actually going on right now.

The assessment underlying it

This is the part most often missing, and the part that really matters. It contains which pages and flows were tested, using which method, and what came out of it. An automated scan tests some requirements well and systematically, but not everything: whether alternative text substantively covers the image, whether the reading order for a screen reader is logical, whether an error message in a form is actually read aloud — these require assessment that a scan cannot fully provide. Every report generated on axessia.eu explicitly states what has and has not been tested, precisely because that boundary is part of a fair assessment and not something to conceal. How that information is obtained is explained on the page that explains where the findings come from.

Important to mention in this section: an overlay widget that claims to automatically make a site accessible is neither a substitute for this assessment nor a demonstrable measure. A supervisory authority asking about the substantiation behind a statement is asking what was tested and with what result, not about a script running on the site.

The improvement plan

What a scan or audit produces is usually a long list of findings at different levels of severity. An improvement plan converts that list into plain language, with a priority and a deadline for each item: what affects the checkout and must come first, what is a minor adjustment that can come later. That plan is part of the file because it shows that not only has testing been done, but work is also being done on what does not yet comply. Anyone who prefers not to structure this themselves can see in the overview of what the subscription delivers per component how the prioritized action list and the statement emerge together from it.

Recording after each change

A website or app rarely stands still: a new payment provider, an updated login flow, a different plugin for the search function. Each of these changes can affect something that previously complied. The file is therefore not a snapshot but something that is maintained. For those who want to know exactly which situation requires which documents — for example, an e-commerce shop with an account environment versus a service without a checkout — the knowledge base with the topics worked out per situation provides a more specific answer than a general overview could offer.

Who can ask about this

Market surveillance authorities are concerned with whether a statement is present and whether it matches what was actually tested. This means the file is not only intended to be published, but also to be shown upon request. For your own situation, and for the question of which format and which reporting route apply in your country, a legal advisor or the competent market surveillance authority remains the appropriate source; this article describes the structure of the file, not the assessment of an individual case.

If you first want to know whether this applies to your organization and where the largest gaps are, then the free quick scan of a few key pages provides an initial indication, without requiring an account for that.

This article is general information and not legal advice.