The accessibility statement template you copied is for a different law

Published 21 August 2026.

Search for “EAA accessibility statement template” and you will find the same twelve-section document over and over. Conformance status, non-accessible content, preparation date, feedback mechanism, enforcement procedure. It looks official because it is official.

It is also written for a different directive, aimed at organisations you are probably not one of.

That template comes from Implementing Decision (EU) 2018/1523, which sets out the model accessibility statement for the Web Accessibility Directive (2016/2102). The Web Accessibility Directive applies to public sector bodies — ministries, municipalities, state hospitals, public universities.

The European Accessibility Act is a different instrument with a different scope, and it does not prescribe a template at all.

Copying the public-sector model is not a disaster. Much of it is sensible, and national transpositions differ — yours may well ask for something close to it. Check what your own member state actually enacted, because that is the text that binds you, not the directive in the abstract. But if you copy the model believing it is the EAA requirement, you will confidently produce a document that satisfies a rule you are not subject to while missing two obligations you are.

Before any of this: does it apply to you?

Microenterprises providing services — fewer than ten people and under €2 million turnover — are exempt from the EAA's service obligations. That exemption does not extend to product manufacturers, and it does not exempt you from other law.

If you are under those thresholds, the rest of this article is optional reading rather than a compliance task. Publishing an honest statement is still a good idea. It is just not the same as being obliged to.

What the EAA actually asks for

Article 13(2) puts the duty on service providers plainly: prepare the information required by Annex V, and explain how the service meets the applicable accessibility requirements.

Annex V then lists what that information contains:

1. A general description of the service in accessible formats.
2. Descriptions and explanations necessary for understanding how the service operates.
3. A description of how the relevant accessibility requirements in Annex I are met.

Three items. No conformance percentage, no prescribed headings, no template.

That is more demanding than it first appears, because point 3 is not “we ran a scanner”. Annex I is the accessibility requirements themselves. You are being asked to walk through what applies to you and describe how you meet it.

The two obligations the public-sector template will not remind you about

It goes in your terms and conditions

The directive says the information assessing how your service meets the accessibility requirements belongs in the general terms and conditions, or an equivalent document.

The pattern you see almost everywhere is a page at /accessibility linked from the footer, and nothing else. That page is useful and you should keep it — but on its own it is not where the directive says the information lives.

If your terms and conditions are a separate document a customer accepts at checkout, that document, or something equivalent to it, is where this has to appear.

It has to exist in oral format too

Article 13(2) requires the information be available in written and oral format, and in a manner accessible to persons with disabilities.

Oral. This is the requirement I have seen discussed least and skipped most.

It does not mean recording a podcast. In practice it means somebody who telephones your support line and asks how accessible your service is must be able to get the answer that way — which implies your support staff know it exists and can read it out or explain it. A statement your own support team has never seen fails this quietly and completely.

What makes a statement survive being read by a hostile expert

The three ways statements fail have nothing to do with formatting.

Claiming conformance you cannot support

“This website is fully compliant with WCAG 2.1 AA” is the single most common sentence in generated statements, and it is almost never true.

Automated testing detects roughly a third of accessibility barriers. If nobody has tested with a screen reader, nobody has tabbed the full checkout, and nobody with a disability has used the thing, then the honest status is partially conformant, and saying so costs you far less than the alternative.

The alternative is documented. In January 2025 the US Federal Trade Commission brought a case against accessiBe over claims that its widget could make any site WCAG compliant, and approved a final order in April requiring the company to pay $1,000,000. The complaint also covered reviews presented as independent that were not. Different jurisdiction, same principle: an accessibility claim is a claim, and unsupported claims are actionable.

Your statement carries your organisation's name, not your vendor's.

Being silent about what was never checked

A statement that lists three known issues implies the rest was examined and passed.

If your evidence is one automated run, several clauses were never evaluated at all — consistent navigation, keyboard operability across a whole journey, whether alt text actually communicates anything. Silence about them reads as a pass, and that inference is the thing you did not intend to make and will be held to anyway.

Name them. “These were not assessed” is a defensible sentence. “We are fully compliant” when they were not assessed is not.

Offering a feedback route that does not work

Every model statement includes a contact for reporting barriers. Most of those addresses go to a mailbox nobody reads.

The feedback mechanism is not decoration. It is the thing a regulator will test first, because it takes them thirty seconds and it tells them whether the rest of the document is real. Send a message to your own accessibility contact and see what happens.

A structure that works

Not a template to paste — the EAA prescribes none, and your service is not mine. But this order holds up:

What this service is, in plain language. Annex V point 1, and the place to be concrete rather than corporate.

Current status, stated exactly as strongly as your evidence supports. If the evidence is automated testing only, say that in the same sentence as the status.

How the requirements are met, walking the applicable parts of Annex I. This is the substance, and it is the part a template cannot write for you.

What is not accessible yet, with what you intend to do and roughly when. A known issue with a date attached reads as competence. The same issue undisclosed reads as concealment.

What was not tested, named clause by clause rather than left to inference.

How to tell us, with a route somebody actually monitors and a response time you will actually hit.

When this was prepared and how, including what tooling and what manual testing. A statement with no date and no method is an assertion.

Where a tool helps, and where it does not

Curbcut drafts the evidence-based parts. It maps findings onto EN 301 549 clauses, ranks them by regulatory exposure rather than by how loudly a rule engine complains, and generates a statement draft.

The generator deliberately will not produce a full-conformance claim from scan data, because scan data cannot support one. Everything requiring a human decision stays a visible [bracket] until a human fills it in. Brackets in a draft are annoying. Brackets are also the only honest output when the input is one automated run.

npx curbcut https://example.com --crawl --statement

Or check a page in your browser with nothing installed, which is the faster way to see what your evidence actually looks like before you write anything.

Our own accessibility statement is written to these rules, including the parts that make us look worse than a generated one would.

The honest part

I am not a lawyer and this is not legal advice. Whether the EAA applies to you, what your national transposition adds, and whether a particular statement discharges your obligation are legal questions about your business.

What I can tell you is that automated testing reaches about a third of the problem, that a statement is a public claim about the other two thirds, and that the gap between those two facts is where organisations get into trouble.

Write the statement you can defend, not the one you would prefer to be true.