The European Accessibility Act (EAA) came into force on 28 June 2025. One of its requirements, set out in Article 13 of the Directive, is that every economic operator covered by the Act must produce and publish an accessibility statement. The statement explains how your product or service meets the accessibility requirements, where it falls short, and what a user can do if they encounter a barrier.
Most companies do not realise this is a separate obligation from "be accessible." You can build the most accessible app in Europe and still be in breach of the EAA if you do not publish the statement. You can also publish a statement and still be in breach if it does not contain what Article 13 says it must.
This post explains, in plain language, what the EAA accessibility statement requires, who is on the hook, what regulators look for, and how to produce one without hiring a consultancy. It is written for compliance officers, COOs, heads of product, and legal counsel who have heard "you need an accessibility statement" and have no clear sense of what that means in practice.
What an EAA accessibility statement actually is
The accessibility statement is a public document. It is published on your website or inside your app's settings, accessible to anyone who looks for it. It is not an internal compliance memo and not something you only show to a regulator on request.
It declares your accessibility position. Specifically, it names the standard you measure your product against (almost always EN 301 549 and Web Content Accessibility Guidelines (WCAG) 2.1 Level AA), it states whether your product fully meets that standard, partially meets it, or does not meet it, and it tells the reader what to do if they find a barrier you missed.
Article 13 of the EAA is the legal hook. Article 14 covers the underlying conformity assessment procedure, which is the internal evidence that backs up what the statement says. The two are linked but distinct. The statement is the public face of your accessibility position. The conformity assessment is the file you can produce when a regulator asks for proof.
Public-sector bodies in the European Union have been publishing accessibility statements since 2018 under the Web Accessibility Directive (WAD), Directive (EU) 2016/2102. The EAA extends the same logic into the private sector. If you have ever clicked an "Accessibility" link in the footer of a government website, you have read a statement of the kind the EAA now expects from private companies.
A statement is not a one-time document. It must reflect the current state of the product. Fix a barrier and the statement updates. Ship a feature that introduces a new barrier and the statement updates again. A document published in 2024 with no review since is not a current statement.
Four things every statement must declare. Everything else is detail layered on top.
What Article 13 of the EAA actually requires
This is the load-bearing section. The EAA itself does not prescribe a single statement template, but the European Commission's Implementing Decision (EU) 2018/1523(opens in new tab) set out a model template for the public sector under the Web Accessibility Directive, and most credible private-sector statements follow the same structure for consistency. National regulators reviewing private-sector statements will recognise that template immediately.
Seven elements. Miss one and your statement is not credible.
1. Identification of the product or service. Name, version, and scope. If you ship a website and a separate mobile app, each needs its own statement, not one generic document covering both. If your mobile app supports e-commerce and your website hosts an unrelated content service, those are separate scopes too.
2. Conformance level. State the standard. Most companies should write "EN 301 549 v3.2.1 (March 2021), incorporating WCAG 2.1 Level AA." Then state which of three positions applies to your product:
- Fully conforms. Every applicable success criterion is met.
- Partially conforms. Most criteria are met, with documented exceptions.
- Does not conform. Significant gaps exist; the statement explains why and what is being done about them.
Most mid-market companies are in "partially conforms." Honesty is required here. Claiming full conformance for a product that visibly fails WCAG criteria is a regulatory risk in itself, because it puts the company in the position of having made a false public declaration.
3. List of non-conformant content and the rationale. Where the product fails, the statement names the failure and the reason. Acceptable reasons under the EAA are narrow. Technical impossibility, disproportionate burden (which has a strict legal test under Article 14), or third-party content the company does not control are the principal categories. "We did not get to it yet" is not a recognised exception.
4. Date of the last assessment. Statements without a date are not credible. A regulator may treat an undated statement as evidence the company is not actively monitoring its product. Most national guidance documents expect annual review at minimum, with updates whenever the product changes meaningfully.
5. Feedback and enforcement contact. A way for users who encounter a barrier to contact the company, get a response, and (if not satisfied) escalate to the national enforcement authority. Many companies miss this entirely. The contact must work. Bouncing email addresses and forms that silently fail are documented findings in regulator audits.
6. The accessibility commitment. A short statement of company policy on accessibility. This is the only soft element. Specific commitments outperform generic language. "We meet WCAG 2.1 Level AA across our consumer-facing apps and review every quarter" is better than "We are committed to accessibility."
7. Effective date. When this version of the statement took effect. Different from the date of last assessment, because the statement may be reissued without a fresh audit. Both dates should appear.
Who has to publish an EAA accessibility statement
The short answer: any economic operator covered by the EAA. The longer answer matters because the test is more specific than "every European company."
In scope:
- Private companies providing covered products or services to consumers in the EU, with more than 10 employees or over EUR 2 million annual turnover. The microenterprise exemption applies only to services (not products), and only when both employee and turnover thresholds are below the limit. Most mid-market companies do not qualify for the exemption.
- Companies headquartered outside the EU that sell into the EU market. EAA enforcement is based on where the product or service is sold, not where the company is registered. A United States retailer with a European Union storefront is in scope.
- Public-sector bodies in EU member states are separately required to publish statements under the Web Accessibility Directive, Directive (EU) 2016/2102, which has been live since 23 September 2018 for new sites, 23 September 2020 for existing sites, and 23 June 2021 for mobile apps.
The EAA covers a defined list of products and services. The principal categories include e-commerce, banking for consumers, e-books, transport ticketing, electronic communications, audiovisual media services, computers and operating systems, payment terminals, ATMs, and self-service kiosks. A consumer mobile app or website that supports any of those services almost certainly falls in scope.
If you are unsure whether your product is covered, our guide to who the EAA applies to has the longer scope analysis. For a deeper read on the harmonised standard your statement will reference, see the EN 301 549 reference page.
Where to publish your accessibility statement
Web products. The statement lives at a stable, discoverable URL. The convention is /accessibility. The link belongs in the site footer, not buried inside a "Legal" submenu next to the privacy policy. Hiding it under Legal is technically compliant in most jurisdictions, but several national guidance documents are explicit that the statement must be discoverable from any page.
Mobile apps. The statement must be reachable from inside the app, usually under "Settings > About" or "Help > Accessibility." It must also be findable on the company's website, because users may not have installed the app yet when they look for it. App store listings now include accessibility metadata fields on both iOS and Android. If the platform supports a statement link, use it.
Format. Statements must be machine-readable. HTML, not a downloaded PDF. PDF-only statements are flagged in compliance audits because they cannot be parsed by assistive technologies in the way the statement itself is meant to demonstrate.
Language. The statement must be available in the language of the consumer market it serves. A pan-European product is expected to publish translated statements in at least the languages of the markets it operates in.
What regulators look for in an EAA accessibility statement
This is the part you will not get from a generic accessibility statement template.
Specificity. Statements that name the standard (EN 301 549 v3.2.1, WCAG 2.1 Level AA), name the version of the product tested, and specify the assessment date are credible. Statements that say only "we are committed to accessibility" are not. Regulators read enough of these to recognise a generic template at a glance.
A current date. A statement last updated 18 months ago suggests the company is not actively monitoring its product. Under Article 14 of the EAA, regulators may issue a request for the underlying conformity assessment if they suspect the public statement is stale. If your statement is dated 2024 and your conformity assessment file is also dated 2024, that is consistent. If your statement is dated 2024 but your product has shipped a major release every quarter since, that is a finding.
An honest non-conformance section. Most products partially conform. Saying so is not an admission of failure, it is a statement of position. Statements that claim full conformance for products visibly failing WCAG 2.1 Level AA invite scrutiny that the company will struggle to satisfy.
A working feedback mechanism. Regulators in some jurisdictions test the contact path themselves. If a complaint email bounces, or a contact form silently fails, or no one responds within the published response window, that is a documented finding.
A link to the national enforcement authority. Each EU member state has designated an enforcement body under the EAA. Germany, France, Spain, Italy, and others have all named theirs. The statement should link to the body relevant to the user's location, not just the company's home jurisdiction.
The pattern is consistent. Regulators do not expect every product to be perfect. They expect every company to demonstrate that it knows where it stands, is honest about it, and is doing something about the gaps. The accessibility statement is the public evidence of that posture. For a wider read on what national regimes look like in practice, see our guide to EAA fines and enforcement.
How to produce an EAA accessibility statement
Three viable paths.
Option A: Write it by hand. Possible if your team has accessibility expertise and you have a current EN 301 549 audit to reference. Time cost: four to eight hours of legal and compliance time per app, plus ongoing maintenance every time the product changes. Accuracy depends entirely on whether the underlying audit data is current. The main risk is drift. Statements written once and then ignored quietly slip out of date as the product changes.
Option B: Use a template. Several public templates exist. The European Commission's Implementing Decision (EU) 2018/1523 published a model for the public sector. Various accessibility consultancies and trade bodies publish private-sector versions. Templates get the structure right but cannot fill in the conformance data. You still need an underlying audit, and the statement is only as accurate as the audit it references. A template plus a one-off external accessibility audit typically costs GBP 15,000 to GBP 50,000 per app, on a six to twelve week engagement.
Option C: Use a platform that generates the statement from your live audit data. This is what AUDITSU does. The platform runs the audit, captures the conformance result for every applicable EN 301 549 and WCAG 2.1 Level AA criterion, and generates a statement directly from that data. When a remediation ticket closes (a non-conformance is fixed), the statement updates automatically. The output is publishable HTML, branded for the customer, and always current.
The trade-off is straightforward. Hand-written and template-based statements are cheap to produce once and expensive to maintain. Platform-generated statements have a higher floor of setup cost (because you also need an audit platform behind them) but eliminate the ongoing maintenance burden. For a single app updated infrequently, options A or B may be enough. For a product that ships changes weekly and is exposed to multiple jurisdictions, option C pays for itself within months.
There is no "no audit" option. The accessibility statement is a public summary of an audit that exists. Skipping the audit and writing the statement anyway is the worst of both worlds: it produces a public document the company cannot defend if a regulator asks for the file behind it. For a wider view of what an accessibility tooling stack looks like, our EAA compliance software buyer's guide maps the four categories and what each one does.
The bar that matters
The accessibility statement is not a legal nicety. It is the public document by which a regulator, a disabled user, a journalist, or a competitor will measure your stated position against your actual position. Get it wrong in either direction (overclaim conformance you cannot back up, or fail to publish at all) and the EAA exposes you. Get it right and the statement is a quiet, durable piece of evidence that your company is doing the work.
Three bars to think about.
The minimum bar is to publish. A statement that exists, names the standard, states a position, and provides a contact is enough to take you out of the "did not publish" category, which is the worst category to be in.
The credible bar is to keep it current. A dated statement that reflects the actual state of the product at a recent assessment beats a perfect statement that has not been touched in two years.
The defensible bar is to tie the statement to live audit data so it cannot drift. If the audit changes, the statement changes. If a ticket closes, the statement updates. That is the position a regulator cannot easily challenge.
AUDITSU generates an EAA-compliant accessibility statement directly from your live audit data, in any of 27 EU jurisdictions, branded for your company. The statement updates automatically as your team fixes issues. See how it works. Beta access is GBP 197 per month with the first month free.