The European Accessibility Act has been in force since 28 June 2025. Ten months in, the conversation has shifted from "what does this require" to "what does enforcement actually look like." National market surveillance authorities are now active in several Member States, and teams without documented compliance work are in a much harder position than they would have been a year ago.
The harmonised standard supporting the EAA is EN 301 549, currently at version 3.3.1. For web content and applications, EN 301 549 maps substantially to WCAG 2.1 Level AA at its core — but teams should be working to WCAG 2.2 now. The newer success criteria address real interaction patterns that WCAG 2.1 left unresolved, including Focus Appearance, Dragging Movements, and Target Size Minimum.
WHAT_ENFORCEMENT_LOOKS_LIKE_NOW
The practical pattern so far has been complaints-driven: a user or advocacy organisation files a complaint with a national authority, the authority investigates and contacts the organisation, and the pressure lands on whoever owns the product roadmap. The Act gives national authorities power to require remediation, impose penalties for persistent non-compliance, and in some cases withdraw products from the market.
One nuance worth noting: there is an exemption for microenterprises providing services — fewer than 10 employees and annual turnover or balance sheet below €2 million. Organisations above that threshold do not have that relief, and most digital product companies do not qualify.
"Accessibility failures are usually process failures before they become code failures."
WHERE_THE_DURABLE_FIX_LIVES
The audit-and-fix approach is losing credibility. It tends to produce a point-in-time clean bill of health while the same issues reappear under a different page name or framework update. The durable fix is making accessibility part of the delivery system: component criteria, QA scripts, release conditions, and evidence collected before sign-off.
Teams that have moved fastest are the ones that embedded WCAG 2.2 acceptance criteria into their design system primitives — and who treat keyboard navigation and screen reader testing as part of the same QA workflow as visual regression, not as a separate specialist audit pass conducted after the code is already merged.
- Work to WCAG 2.2 Level AA, not 2.1 — this is what the harmonised standard now points toward for covered services.
- Prioritize the flows that generate revenue first: checkout, login, password reset, account management, support forms.
- Attach accessibility evidence to release sign-off so a future audit or complaint investigation has something to look at beyond the current state of the product.
- Test keyboard flow, visible focus at all interaction states, zoom behavior at 200%, and error handling with screen readers — these fail silently in most design-system-driven products.
THE_DESIGN_SYSTEM_ANGLE
If shared components reintroduce the same accessibility issues across every new page that uses them, individual page audits will never close the gap. The fix needs to live at the primitive level: color contrast tokens, focus states, error messaging patterns, touch target sizes. Everything above that either inherits the fix or introduces new debt that surfaces in the next complaint.