A compliant accessibility statement under the European Accessibility Act has to do three things: describe the service in an accessible format, explain how the service works, and show how it meets each accessibility requirement that applies to it. Those are the elements Annex V of Directive (EU) 2019/882 spells out for service providers. Notice what is missing: the EAA gives you the required content, not a fixed form. That is the first thing to get straight, because most people searching for "accessibility statement requirements" are picturing the tidy, five-section template from the public-sector rules, which is a different law. This guide covers both. It walks through what the EAA actually requires you to include, shows the prescriptive public-sector model statement people usually have in mind, explains which set applies to you, and covers the part everyone gets wrong: how to fill in the conformance section without claiming more than your testing can back up.
What must an EAA accessibility statement include?
Three elements, set out in Annex V of the EAA. The information you publish has to cover, as far as it matters for the assessment, the design and operation of the service, and it must contain: (a) a general description of the service in accessible formats; (b) the descriptions and explanations needed to understand how the service operates; and (c) a description of how the applicable accessibility requirements in the directive's Annex I are met (Directive (EU) 2019/882, Annex V). Article 13 is the obligation to prepare that information, keep it for as long as the service is in operation, and make it public.
Element (c) is the one that carries weight, and the bare legal text leaves it open. A statement that stands up to scrutiny tends to add structure the directive does not force but auditors expect:
- The standard you tested against. For web content under the EAA, that is EN 301 549, which currently incorporates WCAG 2.1 Level AA.
- Your status per requirement, rather than one pass/fail badge: met, partially met, or not met.
- Known limitations, named plainly, for the parts that fall short today.
- A remediation plan with a rough timeline for the gaps.
- A feedback route so someone can report a barrier and reach a person.
That last item reflects the directive's expectation that users can raise problems, and several member states connect complaint-handling to their enforcement authorities. The EAA overview breaks the underlying accessibility requirements down by sector if you need to work out which parts of Annex I apply.
What does the public-sector model statement require?
This is the version most people mean when they say "accessibility statement requirements", and it is far more prescriptive. It comes from a different law: the Web Accessibility Directive (2016/2102), which covers public sector websites and apps, not private services. Commission Implementing Decision (EU) 2018/1523 gives it a model template with mandatory sections every public-sector statement has to carry:
| Required section | What it must say |
|---|---|
| Compliance status | Whether the site or app is fully, partially, or not compliant with the standard |
| Non-accessible content | The parts that fall short, grouped by reason: non-compliance, disproportionate burden, or content outside the law's scope, with accessible alternatives where relevant |
| Preparation of the statement | The date it was prepared and the method used to assess conformance (self-assessment or third-party evaluation) |
| Feedback mechanism | A description of, and a link to, how users report barriers or request excluded content |
| Enforcement procedure | A description of, and a link to, the complaint route, plus the enforcement body's contact details |
Two details from that decision are worth carrying over even if you are a private business. The statement has to be provided in an accessible format, and a link to it should sit prominently on the homepage or in a static header or footer on every page (Implementing Decision (EU) 2018/1523). Those are sensible defaults regardless of which law binds you.
EAA or public-sector: which requirements apply to you?
It depends on what you are. Public bodies and their websites and apps follow the Web Accessibility Directive and its five-section model statement. Private providers of the consumer services the EAA covers, such as e-commerce, consumer banking, e-books, electronic communications, and passenger transport, follow the EAA's Annex V information duty instead.
The practical upshot: if you are a private business, no EU law hands you a mandatory template. You are free to borrow the public-sector structure, and doing so is a reasonable move, because it is clear, familiar to auditors, and covers the ground element (c) implies anyway. What you must not do is assume the public-sector wording binds you when it does not, or skip the EAA elements because you copied a template that never mentioned them. If your case sits near the microenterprise line for services (fewer than 10 people and turnover or balance sheet total of €2 million or less, both at once), the EAA guide covers whether the information duty applies at all before you worry about its contents.
How do you fill in the conformance section honestly?
This is where a statement is made or broken, because element (c) and the public-sector "compliance status" section both ask you to declare where you stand, and that declaration has to be true. EN 301 549 Annex C gives you the structure: go through each applicable requirement and mark it met, partially met, or not met, with a note. Meeting the relevant parts of EN 301 549 also gives you a presumption of conformity with the EAA's requirements, so it doubles as both the recording format and the technical yardstick (European Commission, M/587).
To fill that in truthfully you have to know where the service actually stands, and that takes two layers of testing. Automated tools clear the machine-detectable defects quickly: missing alt text, low contrast, unlabelled form fields, a missing page language, basic ARIA errors. Manual review handles what a machine cannot judge, such as whether checkout works with a keyboard, whether focus order is logical, and whether alt text is meaningful rather than image123.
How far does automation reach? Deque's analysis of more than 2,000 audits, covering roughly 300,000 issues, found automated testing identified about 57% of issues by volume; estimates that count the share of WCAG success criteria a tool can even evaluate put it nearer 30% (Deque, 2021). Either number leaves a gap only human review closes, which is exactly why a credible statement records limitations instead of declaring a clean sweep. Our WCAG checklist sets out the manual criteria so the part a scanner cannot settle does not get skipped.
The reason to be careful 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 product could make any website WCAG compliant, and the order bars that claim without evidence (FTC, April 2025). The lesson for your statement is direct: record what you tested and fixed, name what you have not, and do not let a generated badge assert conformance the testing does not support.
Where and how must you publish it?
The EAA points to your 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, link it from the footer, and reference it from the terms, which is where users and auditors look first.
Two format rules are not optional. The information has to be public, and it has to be provided in a way that is itself accessible to people with disabilities, so the statement cannot be an inaccessible PDF or an image of text. You also have to keep it for as long as the service runs, which makes it a living document you revise when the service changes, not a one-time publish.
A required-elements checklist
- Describe the service in an accessible format (Annex V (a)).
- Explain how it works clearly enough to understand its operation (Annex V (b)).
- State how it meets each applicable requirement in the EAA's Annex I, per requirement (Annex V (c)).
- Name the standard: WCAG 2.1 AA via EN 301 549, plus any service-specific clauses.
- Record status honestly: met, partially met, or not met, using the EN 301 549 Annex C structure.
- List known limitations and a remediation plan with a rough timeline.
- Give a feedback route so users can report a barrier and reach a person.
- Publish it accessibly, link it from the footer, and keep it current.
You can draft a structured version with our accessibility statement generator, then check the detail against the accessibility statement guide.
Frequently asked questions
What are the required contents of an EAA accessibility statement?
Annex V of the EAA requires three elements: a general description of the service in accessible formats, the explanations needed to understand how the service operates, and a description of how the service meets each applicable accessibility requirement in Annex I. Good statements also add the standard tested against, a per-requirement status, known limitations, and a feedback route.
Does the EAA give a fixed accessibility statement template?
No. The EAA sets out required content in Annex V but no mandatory form. The prescriptive five-section template belongs to the public-sector Web Accessibility Directive (2016/2102) and its Implementing Decision 2018/1523, not the EAA. Private businesses may borrow that structure, but it is not legally imposed on them.
What must a public-sector accessibility statement include?
Five mandatory sections: a compliance status (fully, partially, or not compliant), a list of non-accessible content with reasons, the date and method the statement was prepared, a feedback mechanism, and an enforcement procedure with the enforcement body's contact details.
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 aligned with WCAG 2.2 is expected to be cited later, but until it is, 2.1 AA is the bar.
Can a tool decide my compliance status for me?
No. A tool can draft the document and structure the conformance record, but it cannot judge your conformance. That takes both automated and manual testing, since automation catches only about 30–57% of issues depending on how you count.
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 cannot judge. You will have a real, requirement-level picture to write down, and a defensible statement instead of a guess.
Pavel Charkasau, founder, wcagc.com. Last updated 7 July 2026.
Sources
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — Annex V required information elements (a), (b), (c); Article 13 duty to prepare, keep, and publish. Accessed 7 July 2026.
- Directive (EU) 2016/2102 (Web Accessibility Directive), EUR-Lex — public sector accessibility statement obligation. Accessed 7 July 2026.
- Commission Implementing Decision (EU) 2018/1523, EUR-Lex — model accessibility statement: mandatory sections, accessible format, and prominent placement. Accessed 7 July 2026.
- Latest changes to the accessibility standard (M/587), European Commission — presumption of conformity via EN 301 549. Accessed 7 July 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage figures across more than 2,000 audits. Accessed 7 July 2026.
- FTC approves final order requiring accessiBe to pay $1 million, Federal Trade Commission — deceptive WCAG-compliance claims. Accessed 7 July 2026.