EAA accessibility statement requirements can feel unclear because the European Accessibility Act sets the goal while each country shapes the detail. This guide shows what to include, where to publish it and which national points to confirm before you go live. It is general information, not legal advice.
What an EAA accessibility statement is and who needs one
According to the W3C, an accessibility statement is a public page that tells users how accessible your website or app is. At a minimum it should state your commitment to accessibility, the standard you apply, such as WCAG 2.2, and contact details for reporting problems. Add scope, known limitations and the enforcement contact, based on national rules.
The European Commission explains that the European Accessibility Act is a directive that removes barriers created by different rules in Member States. It covers products and services including banking services, e-books and e-commerce, so online shops are clearly in its sights. For a wider overview, read our European Accessibility Act website guide.
The W3C also notes that public bodies in countries implementing the EU Web Accessibility Directive are required to provide a statement. For private businesses such as ecommerce and SaaS teams, whether and how a statement is mandated depends on how national law applies to your service. Confirm that with qualified counsel.
Core elements every statement should contain
The W3C separates what a statement must have at least from what it advises adding. Use this as your backbone, then layer on any national requirements.
The minimum
- Commitment: a clear statement of commitment to accessibility for people with disabilities.
- Standard applied: for example WCAG 2.2.
- Feedback contact: an email, form or phone number for users who hit a problem.
Strongly advised additions
- Scope: which domains, apps and page types the statement covers.
- Known limitations: listed openly, to avoid frustrating users.
- Measures taken: what your organisation does to keep content accessible.
- Technical prerequisites: such as supported browsers.
- Tested environments: where the content has been tested to work.
- Applicable laws and policies: references to national or local rules.
The enforcement body
Several national regimes expect you to point users to the authority that handles complaints. The references we used do not name a body for each country, so treat this as a detail to confirm: [INSERT: enforcement or market surveillance authority per target country].
Write for users, not lawyers. The W3C suggests saying “videos do not have captions” instead of “WCAG Success Criterion 1.2.2 was not met”. A statement is not a technical assessment or a declaration of conformity, though it can refer to one. The W3C guide to accessibility statements covers this in detail.
Where to publish it and how to keep it current
The W3C says statements should be easy to find. Link them from the footer, help menu, sitemap, about page and other prominent areas. Use one consistent link name across your site, mobile apps and related properties, so users recognise it.
Keeping it current is a process, not a one-off task. Review the page after major releases, when you fix or discover a limitation, and when contact details change. Showing a last-reviewed date is a practical habit, and a stale statement erodes trust.
If you use Accessify, our guide to generating an accessibility statement with Accessify walks through the process. Automated tools help with many issues, but complex sites also need manual testing and fixes in code, and your statement should reflect what is genuinely true after that work.
How an EAA accessibility statement differs by country
The Commission states that Member States had to incorporate the Act into national law by June 2022, and that it monitors implementation. That means each market has its own transposing law, authorities and expectations. The W3C list of web accessibility laws and policies is a useful starting point for finding the rules that apply to you.
We do not state national specifics that our references do not support. Use the table below as a confirmation worksheet for each market you sell into, and re-check it in 2026 as guidance evolves.
| Market | Details to confirm |
|---|---|
| Germany | [INSERT: national law, statement content, language, complaint authority] |
| France | [INSERT: national law, statement content, language, complaint authority] |
| Netherlands | [INSERT: national law, statement content, language, complaint authority] |
| Spain | [INSERT: national law, statement content, language, complaint authority] |
| Italy | [INSERT: national law, statement content, language, complaint authority] |
For a business selling across borders, a common approach is one core statement in plain language, plus local versions or addenda where national rules require extra content. Confirm this with legal counsel before publishing. The European Commission page on the EAA is the official overview.
Copy-ready outline for your statement
Adapt this structure to your business. It follows the W3C guidance and leaves room for national additions. For a fuller draft, see our accessibility statement template.
- 1. Commitment: one or two plain sentences about your commitment to accessibility.
- 2. Scope: [INSERT: domains, apps and page types covered].
- 3. Standard: WCAG 2.2 [INSERT: conformance level you target].
- 4. Measures taken: [INSERT: testing, training, tooling, including manual testing].
- 5. Tested environments: [INSERT: browsers, devices, assistive technologies tested].
- 6. Known limitations: [INSERT: plain-language list and workarounds].
- 7. Feedback contact: [INSERT: email, form, phone, response expectation].
- 8. Enforcement body: [INSERT: authority per country].
- 9. Laws referenced: [INSERT: national references confirmed by counsel].
- 10. Date: [INSERT: last reviewed date].
Statement support: how Accessify and other vendors compare
Our references do not describe competitor statement features, so this table only lists what we can support and what you should verify. Vendor offerings change, so check each vendor’s site for current features and pricing.
| Vendor | Fair strength | Statement support to verify |
|---|---|---|
| Accessify | AI-powered widget with automated remediation, 2-minute install on Shopify, WordPress and more, plans from $19/month | Has a guide for generating a statement; complex sites still need manual testing |
| UserWay | Recognised accessibility vendor with public documentation | [INSERT: verify on vendor’s public page] |
| accessiBe | Recognised accessibility vendor with public documentation | [INSERT: verify on vendor’s public page] |
| AudioEye | Recognised accessibility vendor with public documentation | [INSERT: verify on vendor’s public page] |
Accessify suits small and mid-sized shops and SaaS sites that want fast, automated improvements and a straightforward route to a statement. If you have a complex application, a manual audit, a managed service or an enterprise platform may be the better choice. No tool alone guarantees legal compliance.
Pre-publish checklist
Before your EAA accessibility statement goes live, confirm each item:
- It states your commitment, the standard applied and a working feedback contact.
- Scope and known limitations are accurate and written in plain language.
- Country-specific details, language and enforcement body are confirmed for each market.
- Every claim matches real manual and automated testing results.
- It is linked from the footer, help menu, sitemap and about page with one consistent link name.
- A review date and owner are recorded, and legal counsel has reviewed it.
Frequently Asked Questions
What is an accessibility statement in simple terms?
It is a page that explains how accessible your website or app is for people with disabilities. According to the W3C, it should show commitment, name the standard applied and give contact details. It is written for users, so use plain language rather than legal or technical wording.
Do I need a separate statement for each country?
Not necessarily, but you should check. The references do not set one fixed statement format for every market, and the W3C notes that some situations require particular content. Confirm each target country’s rules, including language and the responsible authority, with qualified legal counsel before choosing one shared or several local versions.
How often should I update my accessibility statement?
Update it whenever your site, known limitations or contact details change. The W3C advises listing known limitations to avoid frustrating users, so outdated entries defeat the purpose. A practical habit is reviewing it after major releases and at regular intervals, then recording the review date on the page.
Is a widget enough to publish an accurate statement?
No. A widget and automated remediation can fix many issues, but complex sites also need manual testing and code fixes. The statement must honestly describe what still falls short. Treat it as a record of real testing, not a promise of full compliance, and never include claims you cannot verify.
Where should I link my accessibility statement?
Link it from several prominent places such as the footer, help menu, sitemap and about page, according to the W3C. Use the same link name everywhere, including across related websites and mobile apps. Consistent naming matters because users look for it at the moment they hit a problem.
What should I write instead of technical WCAG wording?
Describe what users experience. The W3C gives an example: instead of saying WCAG Success Criterion 1.2.2 was not met, say videos do not have captions. Name the barrier, the affected content and any workaround, then add contact details so users can report problems and ask for help.
Want a faster route to a clear, accurate statement? Explore Accessify at accessify.app.
