Skip to content
wcagc
←Back to blog
EAAaccessibility-statementEN 301 549

Do you need an accessibility statement under the EAA?

A plain-language guide to what the European Accessibility Act asks in-scope services to publish, and how it differs from a public-sector statement.

P

Pavel Charkasau

If your service falls under the European Accessibility Act, then yes, you need to publish information about how it meets the accessibility requirements. But the word "statement" trips people up. The EAA does not hand you a fixed template called an "accessibility statement," the way the public-sector Web Accessibility Directive does. Instead, Directive (EU) 2019/882 tells service providers to prepare information, in line with its Annex V, that explains how the service meets the accessibility requirements, and to make that information public. So an EAA accessibility statement is best understood as a duty to document and publish, not a form to fill in. The practical question is what to put in it, where to publish it, and how honest to be about the parts a machine can't confirm. This guide walks through all three, and clears up the confusion between the EAA and the public-sector rules people often mix it up with.

Does the EAA require an accessibility statement?

It requires the substance of one, not the label. Under Article 13 and Annex V of the EAA, a service provider has to prepare information explaining how the service meets the applicable accessibility requirements, keep that information for as long as the service runs, and make it available to the public in a way that is itself accessible to people with disabilities. The directive applies across the EU from 28 June 2025, so this is a current obligation, not a future one (European Commission).

Where this catches people out: the EAA never prescribes a single official "accessibility statement" document with a fixed structure. That model statement belongs to a different law, Directive (EU) 2016/2102, the Web Accessibility Directive, which covers public sector websites and apps and comes with a Commission-issued template (Implementing Decision (EU) 2018/1523). If you run a private business in scope of the EAA, you follow the EAA's information duty, which is more open-ended about format. Plenty of guidance online blends the two, so it is worth knowing which law you are actually under.

Who has to publish this information?

Providers of the consumer-facing services the EAA covers, if they are above the small-business line. On the web, the services most often in scope are e-commerce, consumer banking and many financial services, e-books and reading software, electronic communications, passenger transport sites and apps, and access to audiovisual media services. If you sell to EU consumers, your location does not get you out: a company based outside the EU still has to comply for the EU market.

There is one carve-out, and it is narrower than people hope. A business that provides a service and has fewer than 10 people and an annual turnover or balance sheet total of €2 million or less sits outside the EAA's service obligations (Directive (EU) 2019/882, Article 4 and Recital 70). Both conditions have to be true at once. Cross either threshold and the exemption is gone, and the information duty applies. The microenterprise relief also does not extend to businesses that make products. Our EAA overview breaks the scope down sector by sector if your case is borderline.

What does the information have to contain?

Annex V sets out the elements. The information shall, where applicable, include a general description of the service in accessible formats, the descriptions and explanations needed to understand how the service operates, and a description of how the service meets the accessibility requirements in the directive's Annex I (Directive (EU) 2019/882, Annex V). In plain terms: say what the service is, explain how it works, and show how it satisfies each accessibility requirement that applies to it.

A statement that holds up tends to carry a few things beyond the bare legal minimum:

  • A conformance target. State the standard you are measuring against. For web content under the EAA that is EN 301 549, which currently incorporates WCAG 2.1 Level AA.
  • Your current status, per requirement. Met, partially met, or not met, rather than a single pass/fail badge.
  • Known limitations. The specific areas that fall short today, named plainly.
  • A plan and a timeline. What you are fixing and roughly when.
  • A feedback route. A way for someone to report a barrier and reach a human.

That last point matters because the directive also expects users to be able to raise problems, and several member states tie complaint-handling to their enforcement authorities. The honest version of a statement records documented effort, not a perfect score. Claiming more than you can show is the mistake regulators have already punished, which is the next section.

Where do you publish it, and in what format?

The EAA points to the general terms and conditions, or an equivalent document, as the place to set out how the service meets the requirements (Directive (EU) 2019/882, Annex V). In practice most teams publish a dedicated accessibility page and link to it from the footer, which is where users and auditors look first, and reference it from the terms.

Two format rules come straight from the text. The information has to be available to the public, and it has to be provided in a way that is accessible to people with disabilities, so the statement itself can't be an inaccessible PDF or an image of text. The provider also has to keep the information for as long as the service is in operation, which means treating it as a living document you revise when the service changes, not a one-time publish.

How do you actually document conformance?

This is where EN 301 549 earns its place. The standard's Annex C gives a clause-by-clause structure for recording conformance: you go through each applicable requirement and mark it met, partially met, or not met, with notes. Meeting the relevant parts of EN 301 549 also gives you a presumption of conformity with the EAA's requirements, so it is both the documentation format and the technical yardstick (European Commission, M/587).

To fill that in honestly, you need to know where your service actually stands, and that takes two layers of testing. Automated tools catch the high-frequency, machine-detectable defects fast: missing alt text, low contrast, unlabelled form fields, missing page language, basic ARIA mistakes. Manual review covers what a machine can't judge, like whether you can complete checkout with a keyboard, whether focus order makes sense, and whether alt text is meaningful rather than image123.

How far does automation get you? Deque's analysis of more than 2,000 audits across roughly 300,000 issues found automated testing identified about 57% of issues by volume; more conservative estimates that count the share of WCAG success criteria put it closer to 30% (Deque, 2021). Either figure leaves a real gap that only human review closes. That gap is exactly why a credible statement records limitations instead of declaring victory. Our WCAG checklist tool gives you the manual list so the "not tested by a machine" part doesn't get skipped.

Can a tool just generate the statement for me?

A tool can draft the document and structure the conformance record. It cannot decide your conformance for you, and you should be wary of anything that says it can. The reason is the same one behind the strongest selling point in this whole area: accessibility lives in your code, and a statement is only as true as the testing behind it.

The cost of overstating is on the public record. In April 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its AI product could make any website WCAG compliant, and the order bars the company from making that claim without evidence (FTC, April 2025). The lesson for your statement is direct: document what you have tested and fixed, name what you haven't, and don't let a generated badge claim conformance the testing doesn't support. You can draft a structured statement with our accessibility statement generator, then check the detail against the accessibility statement guide.

A short checklist for an EAA statement

  1. Confirm you're in scope. Selling a covered service to EU consumers, above the microenterprise line? Then the information duty applies.
  2. Pick the target. WCAG 2.1 AA via EN 301 549, plus any service-specific clauses.
  3. Test in two layers. Scan for the machine-detectable issues, then run a manual pass for the rest.
  4. Record status per requirement. Use the EN 301 549 Annex C structure: met, partially met, not met.
  5. Write it honestly. Target, current status, known limitations, a remediation plan, and a feedback contact.
  6. Publish accessibly and keep it current. Link it from the footer, reference it from your terms, and revise it when the service changes.

Frequently asked questions

Is an accessibility statement mandatory under the EAA?

For in-scope services, the substance is mandatory: you must prepare and publish information explaining how the service meets the accessibility requirements, per Article 13 and Annex V. The EAA does not impose a fixed template, but the duty to document and publish is not optional.

Is the EAA statement the same as the public-sector accessibility statement?

No. The model accessibility statement with a set template comes from the Web Accessibility Directive (2016/2102) for public sector bodies. The EAA covers private services and is more open about format, while still requiring you to explain how the service meets the requirements.

What standard should the statement reference?

EN 301 549, which currently incorporates WCAG 2.1 Level AA for web content. A v4.1.1 update referencing WCAG 2.2 is expected, but until it is formally cited, 2.1 AA is the bar.

Where should I publish the accessibility statement?

The EAA points to the general terms and conditions or an equivalent document. In practice, publish a dedicated, accessible accessibility page, link it from the footer, and reference it from your terms.

Can I rely on the statement alone to meet the EAA?

No. The statement documents your conformance and effort; it does not create conformance. The underlying service still has to meet the requirements, and confirming that takes both automated and manual testing.

See where your service stands

A statement is only as honest as the testing behind it, so start with the testing. Run a free scan to find the machine-detectable issues on your key pages, then work through the manual checklist for what a scanner can't judge. You'll have a real conformance picture to write down, and a defensible statement instead of a guess.

Pavel Charkasau, founder, wcagc.com. Last updated 26 June 2026.

Sources