Europe · Compliance guide
EAA 2025 compliance for developers
The European Accessibility Act (Directive (EU) 2019/882) became enforceable across all 27 EU member states on 28 June 2025. This guide explains what the law actually requires in engineering terms — not marketing terms — and shows you how to put it in a CI pipeline before the demand letters arrive.
What EAA 2025 is (in plain English)
The European Accessibility Act (Directive (EU) 2019/882) is the EU's unified accessibility law for digital products and services. It replaces a fragmented patchwork of national rules with one standard across the EU single market. Member states had until 28 June 2022 to transpose it into national law; the act then became enforceable against private-sector operators on 28 June 2025.
Unlike the ADA in the U.S., the EAA doesn't wait for courts to decide what "accessible" means — it points at EN 301 549, the European accessibility standard, which in turn incorporates WCAG 2.1 Level AA as the baseline for web content. WCAG 2.2 AA has been added in the most recent revision (EN 301 549 v3.2.1).
Who it applies to
The EAA applies to private-sector operators providing any of the following to consumers in the EU:
- E-commerce: online stores, marketplaces, booking platforms, ticketing.
- Banking and financial services (consumer-facing): online banking, mobile banking apps, payment services.
- E-book services and e-readers.
- Audiovisual media services (consumer-facing VoD, streaming).
- Electronic communications services (messaging, emergency calls).
- Transport services: ticketing, booking, check-in, real-time info.
- Consumer-facing computer hardware + operating systems (e.g., a laptop vendor's OS).
Microenterprise exemption: companies with fewer than 10 employees andunder €2M annual turnover providing services are exempt from EAA service obligations. Product manufacturers don't get this exemption.
Non-EU companies are in scope if they sell to EU consumers. A U.S. e-commerce site accepting EU orders falls under the EAA just like a German site.
Technical requirements — EN 301 549 / WCAG 2.1 AA
For web content, the EAA references EN 301 549 v3.2.1, which incorporates WCAG 2.1 AA. Practically, this means:
- Alt text for informative images (not for decorative ones — decorative images should have
alt=""). - Keyboard-only operation: every mouse action must have a keyboard equivalent, and no keyboard traps.
- 4.5:1 contrast ratio for body text, 3:1 for large text and for UI components and meaningful graphics.
- Semantic headings in order (h1 → h2 → h3), not skipping levels.
- Programmatic form labels associated with every input —
<label for="x">oraria-labelledby. Placeholder text alone is not sufficient. - Screen-reader support for NVDA, JAWS, VoiceOver. The DOM order and ARIA semantics must match the visual order.
- Focus visible: a clear outline or ring when an element has keyboard focus.
- No flashing content above 3 flashes per second (seizure risk).
- Page language declared:
<html lang="en">. Every EU language the site supports must be declared per sub-section.
Penalties and enforcement (by member state)
The EAA requires each member state to set "effective, proportionate and dissuasive" penalties. In practice, penalty structure varies — but several member states are aggressive:
- Germany (BFSG): fines up to €100,000 per violation; repeat violators can face service-prohibition orders.
- Ireland: fines up to €60,000 per infringement and up to 18 months imprisonment for directors in extreme cases.
- France (LCEN + EAA transposition): up to €300,000 for corporate violations; consumers can bring civil actions with strict liability for accessibility failures.
- Italy: up to 5% of annual turnover for non-compliant products/services per the national transposition.
- Spain: escalating tiers with maximum fines up to €1,000,000 for "very serious" infringements that affect a large number of users.
Unlike U.S. ADA cases — which typically end in a settlement of $5K-50K — EU enforcement can be administrative (regulator-led, not consumer-led) and can result in mandatory remediation orders with deadlines. Missing those deadlines is what triggers the large fines.
Why accessibility overlay widgets don't protect you
If you're looking at this page because a vendor offered to "make you EAA-compliant" with a JavaScript widget that adds a small button to your site, stop. The FTC settled with accessiBe for $1,000,000in January 2025, specifically over the claim that their overlay made sites compliant. The FTC's allegation was that this claim was deceptive.
From a strict EAA compliance standpoint: EN 301 549 specifies requirements at the source level. An overlay that programmatically injects ARIA on top of broken HTML does not change the underlying source — and a regulator or a consumer association running an axe-core scan will see the same violations that existed before the overlay was installed.
Research from Princeton (Van Lee et al., 2023) documented cases where overlay-injected ARIA actively harmed screen-reader users because the injected roles conflicted with the semantic structure of the underlying HTML.
How to comply — a six-step process
- Baseline scan. Run axe-core 4.11 against your homepage + 3-5 representative pages. Expect 30-80 violations on a typical site that has not been audited. Half will be trivial (missing alt, missing label); half will need real work.
- Fix at the source. Edit your React / Vue / WordPress / Next.js / Astro templates — do not wrap a band-aid script over a broken page. The EAA cares about the served HTML, not whatever runs in the browser after page load.
- Accessibility in CI. Install an accessibility scanner in your pull-request pipeline. Fail the build at a severity threshold you can actually maintain (
seriousis a good starting point). This is what prevents regressions in the months between audits. - Manual audit for the long tail. Automated tools (axe-core, WAVE, Lighthouse) catch roughly 57% of WCAG violations. Cognitive load, screen-reader flow, form error recovery, and video captioning can only be fully assessed by a human. Budget for one accessibility auditor engagement per year.
- Publish an accessibility statement.The EAA (and WAD Directive (EU) 2016/2102 for public-sector sites) requires a public statement that describes the site's conformance status, known non-compliant content, and a mechanism for users to report barriers.
- Keep an audit trail.Retain scan reports and PR review artifacts. When a regulator investigates, the question isn't whether you're 100% compliant — it's whether you're making systematic good-faith effort. Reports from a CI pipeline are the easiest evidence of that.
Accessibility statement — what the EAA requires
The EAA requires an accessibility statement on every covered digital service. The exact format varies by member state transposition, but at minimum it must include:
- Conformance status: "fully", "partially", or "not" compliant with the referenced standard (EN 301 549 / WCAG 2.1 AA).
- Known non-compliant content with a reason (disproportionate burden under Art. 14 EAA, or exemption under Annex V).
- Contact information for accessibility feedback (named person or team, email, preferably also phone).
- Enforcement procedure: the national regulator the user can escalate to if the operator doesn't respond.
- Methodology: how conformance was assessed (self-assessment vs. third-party audit, tools used, date).
- Last updated date.
- The statement itself must be accessible. Posting it as a scanned PDF without an underlying text layer is itself a violation.
axle's statement generator produces an EAA-compliant statement in Hebrew (Israeli תקנה 35) and English. Multi-language support for all EU languages is on the Team plan.
How axle helps
axle is a compliance CI toolkit designed specifically for teams that need to hit EN 301 549 / WCAG 2.1 AA on every release, not just at audit time.
- GitHub Action. Scans every pull request with axe-core 4.11, blocks merges when violations exceed your threshold. Claude Sonnet proposes source-code fix diffs inline in the PR comment so reviewers see a complete fix, not just a finding.
- Platform plugins for Netlify, Cloudflare Pages, and Vercel. Same scan, your existing pipeline.
- WordPress plugin. Client-side scanner runs in the admin browser — works for any site, including staging behind VPN or basic auth.
- Accessibility statement generator that meets EAA statement requirements, with a hosted verified URL (
axle-iota.vercel.app/s/<id>). Tamper-evident, timestamped, indexable — exactly what a regulator wants to see linked from your footer. - Audit trail. Every scan result is retained in your private dashboard as evidence of systematic monitoring.