Accessibility law in Europe in 2026: the European Accessibility Act, in force and now enforced

For years, web accessibility obligations in the EU private sector were a patchwork: strong rules for public-sector sites, a scattering of national laws for everyone else, and a lot of "we'll get to it". That changed on 28 June 2025, when the European Accessibility Act became applicable across the Union. 2026 is the first full year of it being live, and enforced.

What changed on 28 June 2025#

• The European Accessibility Act (Directive (EU) 2019/882, "the EAA") was adopted in 2019. Member states had to write it into national law by 28 June 2022.
• Its requirements apply to products placed on the market and services provided to consumers from 28 June 2025. Products and services that existed before then get transition time (below), but new ones must comply now.
• It sets one EU-wide baseline for a defined list of consumer products and services, replacing the "depends which country" situation for those categories.

Who is in scope#

Products

• Consumer computers and their operating systems
• Smartphones and other consumer communication devices
• Self-service terminals: ATMs, ticketing machines, check-in machines, and interactive payment terminals
• TV equipment for digital television services
• E-readers

Services

• E-commerce: consumer-facing online sales of goods and services
• Consumer banking services
• Electronic communications services
• Passenger transport: websites, mobile apps, e-ticketing, electronic tickets and real-time travel information (air, bus, rail, waterborne)
• Access to audiovisual media services: the website or app and its programme guides, not the programmes themselves
• E-books and dedicated reading software

The "disproportionate burden" and "fundamental alteration" outs

A business can claim that full conformance would impose a disproportionate burden, or would require a fundamental alteration of the product or service. These are real, but they are not a shrug: you must carry out and document the assessment against criteria in the law, apply accessibility as far as it does not impose that burden, re-assess periodically, and be able to produce the assessment for the authorities on request.

The technical bar: EN 301 549 and WCAG#

The EAA itself is written as functional requirements ("perceivable, operable, understandable"). The concrete yardstick is the harmonised European standard EN 301 549: build to it and you get a presumption of conformity. For web content and apps, EN 301 549 incorporates WCAG 2.1 Level AA.

Services in scope must also publish accessibility information, explaining how the service meets the requirements, in an accessible format.

How it is enforced#

There is no single EU accessibility regulator. Each member state designates its own authorities:

• Market surveillance authorities for products, and separate service-compliance authorities for services.
• Consumer complaint mechanisms. Individuals and representative organisations can file complaints, and courts or authorities can be engaged.
• Authorities can require corrective action within a deadline, restrict or withdraw a non-compliant product, and impose penalties.
• Penalties are set nationally and must be "effective, proportionate and dissuasive". In practice they range from four-figure to six-figure fines depending on the country, the severity, and whether the infringement is ongoing. Some regimes count per-infringement.

The enforcement risk in 2026 is less "a surprise regulator fine" and more a documented complaint, a corrective-action order with a public deadline, and B2B customers and public buyers asking for a conformance report you do not have.

Deadlines still ahead#

Context: the public-sector directive#

The Web Accessibility Directive (EU) 2016/2102 has already required public-sector bodies' websites and mobile apps to meet EN 301 549 since staggered deadlines between 2019 and 2021, with a mandatory, published accessibility statement and periodic monitoring by each member state. The EAA extends comparable expectations to the private-sector categories above. If you sell to the public sector, you have effectively been in scope for years already.

Country notes#

The practical takeaway: if you serve consumers in multiple EU markets, the technical target is the same everywhere (EN 301 549 / WCAG), but the obligations, documentation and penalties are set country by country.

What 2026 looks like in practice#

• Enforcement ramp. Authorities are staffing and publishing guidance; the first corrective orders and complaint outcomes are working through.
• Overlays are not a strategy. Accessibility-overlay widgets are viewed with scepticism by regulators, advocacy groups and courts; they do not create conformance and can introduce their own barriers.
• Procurement pressure. RFPs and vendor due-diligence now routinely ask for an accessibility conformance report (EN 301 549 / WCAG 2.2 AA) up front.
• Risk concentration. Complaint activity clusters in e-commerce, banking and travel: high-traffic, high-friction consumer journeys.

A front-end compliance checklist#

None of this is exotic. It is disciplined web engineering.

1. Semantic HTML first. Real button, a, label, fieldset, headings in order. ARIA only to fill gaps, never to paper over the wrong element.
2. Keyboard operable, everything. Every interactive element reachable and usable with the keyboard alone; no traps; logical tab order.
3. Visible focus. A clear focus indicator on every focusable element (and with 2.2, focus not hidden behind sticky headers).
4. SPA focus management. On route change, move focus to the new view's heading and announce it; do not leave focus on a stale element.
5. Forms. Programmatic label for every field; errors associated with their input and announced; instructions not conveyed by placeholder alone.
6. Colour and contrast. 4.5:1 for body text, 3:1 for large text and UI components; never use colour as the only signal.
7. Target size and spacing (WCAG 2.2) for touch controls.
8. Motion. Honour prefers-reduced-motion; no content that flashes more than three times a second.
9. Names for icon-only controls. An accessible name on every icon button, close control and menu toggle.
10. Dynamic updates. Live regions for async results, toasts and validation summaries.
11. Media. Captions and transcripts; audio description where relevant.
12. Documents. Accessible PDFs; for e-books, valid accessibility metadata and structure (EPUB).
13. Third-party widgets are your liability. Payment iframes, chat, map, cookie banners: audit them. A non-conformant embed is still your non-conformance.
14. Test in layers. Automated tools (axe, Lighthouse in CI) catch roughly a third of issues; then manual keyboard-only, a real screen reader (NVDA, VoiceOver, TalkBack), and 200-400% zoom / reflow.
15. Publish an accessibility statement and keep it current.
16. Get an external audit against EN 301 549 / WCAG 2.2 AA, fix findings, and re-audit on a cadence (at least yearly and after major redesigns).
17. Make it continuous. Accessibility acceptance criteria on tickets, an axe check in the PR pipeline, and a component library that is accessible by default so product teams inherit it.