Your EAA Accessibility Statement: What It Must Contain and How to Write It

Most webshop operators know they need to make their site accessible. Fewer realise that publishing an accessibility statement is itself a separate legal obligation - and that getting it wrong, or skipping it entirely, is its own compliance failure.

The European Accessibility Act came into force on 28 June 2025. Since that date, every in-scope private business must not only meet the accessibility requirements but also publish a statement explaining how it does so. You can build the most accessible shop in Europe and still be in breach if the statement is missing. You can also publish a statement and still be in breach if it doesn't contain what the law requires.

This post explains what the EAA accessibility statement must include, how it differs from the public-sector template many teams already know, and gives you a section-by-section structure you can adapt and publish today.

---

Why the statement is a standalone legal obligation

The legal hook is Article 13 of Directive (EU) 2019/882. It requires service providers to prepare information in accordance with Annex V of the EAA and explain how their services meet the applicable accessibility requirements. That information must be made available to the public in written and oral format, including in a manner accessible to persons with disabilities.

In plain terms: the statement is not a nice-to-have summary of your good intentions. It is a documented, public declaration that regulators can - and do - check. Market surveillance authorities reviewing a complaint will look at your statement first. If it's absent, vague, or contradicted by the actual state of the site, that's a finding on its own.

The financial stakes are real. France imposes an annual penalty of €25,000 specifically for a missing accessibility statement, separate from any fines for the underlying accessibility failures. Germany's transposition (the BFSG) allows fines of up to €100,000 per violation for non-compliant products or services. And in November 2025, French authorities filed proceedings against major retailers including Auchan, Carrefour, and E.Leclerc - with the absence of accessibility statements cited as part of the case.

---

How the EAA statement differs from the WAD template you may already know

If your team has dealt with public-sector accessibility before, you'll be familiar with the Web Accessibility Directive (WAD) and the model statement template set out in Implementing Decision (EU) 2018/1523. That template is a reasonable structural reference, and national regulators will recognise it. But the two frameworks are not the same thing.

The core difference is purpose. The WAD is a digital-only directive aimed at public-sector bodies - government websites, public universities, local authorities. Its statement is primarily a monitoring and transparency mechanism for citizens accessing public services.

The EAA is a consumer protection law. It extends accessibility obligations to private companies and commercial services - e-commerce, banking, telecoms, transport - and goes beyond digital to cover hardware and consumer services too. Its statement is more product- and service-technical: it needs to explain how the specific service meets the Annex I functional requirements, not just tick a box confirming awareness of WCAG.

Here's a quick comparison:

One practical consequence: if you have a website and a separate mobile app, each needs its own statement. A single generic document covering both is not sufficient.

Another: some national transpositions add requirements on top of the EAA baseline. For example, German law requires service providers to name the competent market surveillance authority in the statement. If you operate across multiple EU countries, check each transposition.

---

The six elements your EAA accessibility statement must cover

The EAA does not prescribe a single template, but Annex V and Article 13 together define what the statement must contain. Here is each element, what it means in practice, and what to write.

1. Commitment and scope

Open with a clear statement of your organisation's commitment to accessibility and the purpose of the document. Then define scope precisely: which product or service this statement covers, which version or URL, and whether any parts of the service are still under review or not yet assessed.

Scope matters more than most teams realise. If your checkout flow has been audited but your account management pages haven't, say so. Vague scope language ("this statement covers our digital services") gives regulators nothing to work with and users nothing to rely on.

What to write:

"[Company name] is committed to making [service name] accessible to all users, including people with disabilities. This statement covers [specific URL / app name / version], last reviewed on [date]. The following areas are currently under accessibility review and are not covered by this statement: [list]."

2. Description of the service in an accessible format

This is a requirement that often gets skipped. The EAA requires a general description of the service in an accessible format, plus explanations necessary to understand how the service is provided. In practice, this means a plain-language summary of what the service does and how users interact with it - written so that someone using a screen reader or with a cognitive disability can understand it without needing to navigate the service itself.

Think of it as the "what this is and how it works" section. For a webshop: describe the browsing, product selection, checkout, and account management flows in plain language.

What to write:

"[Service name] is an online shop where customers can browse products, add items to a basket, and complete purchases using a range of payment methods. The service is available via web browser and as a mobile app for iOS and Android. Customer accounts allow order tracking and saved preferences."

3. Conformance standard and compliance status

State the standard you are measuring against - almost always EN 301 549, which incorporates WCAG 2.1 Level AA for web content - and declare your compliance status clearly. Three statuses are recognised: fully compliant, partially compliant, or not compliant.

Do not use hedge language. Phrases like "we strive for accessibility" or "the site is broadly accessible" are not recognised compliance states and will be treated as a finding by auditors. An explicit "partially compliant" with a list of known gaps is the most defensible position for most mid-market services - and the most honest.

A statement claiming full compliance for a service that visibly fails WCAG 2.1 Level AA criteria is a documented contradiction. Regulators find these easy to act on.

What to write:

"[Service name] is partially compliant with EN 301 549 v3.2.1 (incorporating WCAG 2.1 Level AA). The known non-conformances are listed in Section 5 below."

4. Specific accessibility features

List the concrete accessibility features your service provides. This is where you demonstrate the work, not just claim it. Be specific: generic statements ("we support assistive technologies") carry little weight.

Examples of what to include:

• Screen reader compatibility: tested with NVDA and JAWS on Windows; VoiceOver on iOS/macOS
• Keyboard operability: all interactive elements reachable and operable without a mouse
• Text alternatives: all meaningful images have descriptive alt text; decorative images are marked as such
• Colour contrast: text meets WCAG 2.1 AA contrast ratios (4.5:1 for normal text, 3:1 for large text)
• Resizable text: content reflows correctly up to 200% zoom without horizontal scrolling
• Plain language: product descriptions and checkout instructions written at a clear reading level
• Captions: video content includes accurate captions

The assessment method matters too. State whether the evaluation was a self-assessment, an external audit, automated testing, or a combination - and which assistive technologies were tested. This makes the statement credible and shows claims are based on structured testing rather than assumption.

5. Known limitations and remediation plans

This is the section most teams are reluctant to write. Write it anyway. Listing known gaps honestly is not an admission of failure - it is a legal requirement and a signal of good faith to both users and regulators.

For each known limitation, state: what the issue is, which part of the service it affects, and (where possible) when you expect to fix it.

What to write:

"The following content does not currently meet the accessibility requirements: - PDF product catalogues published before June 2025 are not fully tagged for screen reader use. We are reviewing these on a rolling basis; remediation is planned by [date]. - The live chat widget provided by [third-party vendor] does not fully support keyboard navigation. We have raised this with the vendor and are evaluating alternatives."

Note: third-party content you do not control is a recognised limitation, but you still need to name it and explain what you are doing about it.

6. Feedback and contact mechanism

Users who encounter a barrier must have a way to report it and get a response. The EAA requires this. The feedback channel itself must be accessible - a form that fails keyboard navigation defeats the purpose.

Include: a direct email address or accessible web form, the name of the team or role responsible, and what users can expect to happen next (response time, escalation path).

What to write:

"If you experience an accessibility barrier on [service name], or if you need content in an alternative format, please contact us: Email: [accessibility@yourcompany.com] We aim to respond within [X] working days. If you are not satisfied with our response, you can contact [national enforcement body] at [URL]."

The last sentence - pointing to the national enforcement body - is required in some member states (Germany, for example) and is good practice everywhere.

---

A copyable skeleton

Here is the full structure in one place. Replace the bracketed text with your own content.

# Accessibility Statement for [Service Name]

## 1. Commitment and scope
[Company name] is committed to making [service name] accessible to all users,
including people with disabilities. This statement covers [URL / app / version],
last reviewed on [date]. [Any areas under review or excluded.]

## 2. About this service
[Plain-language description of what the service does and how users interact with it.]

## 3. Conformance status
This service is [fully / partially / not] compliant with EN 301 549 v3.2.1,
which incorporates WCAG 2.1 Level AA.
Assessment method: [self-evaluation / external audit / automated testing + manual review].
Assistive technologies tested: [NVDA, JAWS, VoiceOver, keyboard-only navigation, etc.]

## 4. Accessibility features
- [Feature 1, e.g. full keyboard operability]
- [Feature 2, e.g. screen reader compatibility with NVDA and VoiceOver]
- [Feature 3, e.g. text alternatives for all meaningful images]
- [Feature 4, e.g. captions on all video content]
- [Add or remove as applicable]

## 5. Known limitations
The following content or features do not currently meet the requirements:
- [Issue, affected area, planned fix date]
- [Issue, affected area, planned fix date]

## 6. Feedback and contact
If you experience an accessibility barrier, please contact:
Email: [accessibility@yourcompany.com]
[Phone / accessible web form]
We aim to respond within [X] working days.
To escalate: [national enforcement body and URL]

Statement prepared: [date]
Next scheduled review: [date]

---

Where and how to publish it

The statement must be publicly accessible and easy to find. Standard practice is a persistent link in the website footer - the same place users expect to find privacy policies and terms. For mobile apps, the statement should also be reachable from within the app, typically under Settings > About or Help > Accessibility.

The EAA allows you to include the public part of the statement in your terms and conditions or an equivalent document, but a dedicated accessibility page is better practice: it's easier to find, easier to update, and easier for regulators to review.

A few practical rules:

• The page itself must be accessible. An accessibility statement on an inaccessible page is a contradiction that auditors will note.
• Date it. Include the date it was prepared and the date of the last review.
• Don't use an overlay as a substitute. Accessibility overlays do not satisfy the EAA's requirements and have been found to interfere with the assistive technologies used by people with disabilities. The statement must reflect real conformance work, not a widget layered on top.
• Keep it in sync with reality. Fix a barrier and update the statement. Ship a feature that introduces a new barrier and update it again. A static document that drifts from the actual state of the service is a liability, not an asset.

---

Check your statement is complete

Use this widget to run through the required elements before you publish.

---

The honest close

The EAA accessibility statement is not a marketing document. It is a legal declaration about the current state of your service, written for users who depend on that information to decide whether and how they can use what you offer.

A statement that honestly says "partially compliant - here are the gaps, here is the plan" does three things at once: it meets the legal requirement, it gives users with disabilities the information they need, and it demonstrates to regulators that you are engaged with the problem rather than ignoring it.

A statement that claims full compliance when the site fails basic WCAG criteria is a documented contradiction that makes enforcement easier, not harder. And no statement at all is simply a separate breach on top of whatever accessibility failures already exist.

Write the statement. Keep it honest. Keep it current. That's the whole job.

For a broader picture of what the EAA requires beyond the statement - scope, technical standards, enforcement timelines - see our European Accessibility Act compliance guide.