The European Accessibility Act has been in force since 28 June 2025. Nearly twelve 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 current harmonised ICT accessibility reference is EN 301 549 v3.2.1, which maps substantially to WCAG 2.1 Level AA for web content and applications. ETSI's public materials now show the EAA-focused revision work moving through draft V4.1.0 toward a planned V4.1.1 publication in 2026. Teams should treat WCAG 2.2 as the working delivery baseline while documenting the exact standard version used for formal evidence, and should not cite a draft as the harmonised evidence standard until it is final and referenced.
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 as the practical delivery baseline, while recording the EN 301 549 version used for formal conformance evidence.
- 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.
WCAG_2_2_NEW_CRITERIA_IN_PRACTICE
The four new Level AA success criteria in WCAG 2.2 address patterns that were common in existing products and poorly handled by the previous standard. Focus Not Obscured (SC 2.4.11) catches sticky headers, cookie banners, and chat widgets that hide the focused control. Accessible Authentication (SC 3.3.8) catches login and recovery flows that require memorisation, transcription, or puzzle solving without an accessible alternative.
Dragging Movements (SC 2.5.7) requires that functionality implemented via drag can also be operated with a single pointer without a path-dependent gesture. This matters for components that use drag-and-drop sorting, resizable panels, or canvas-based interactions. Many design systems implemented drag-only interaction patterns because they felt natural on desktop; SC 2.5.7 requires a non-drag alternative for each of those patterns.
Target Size Minimum (SC 2.5.8) requires that interactive targets are at least 24 by 24 CSS pixels, with exceptions for inline text links and targets that have sufficient spacing. This catches icon-only buttons at 16 or 20 pixels that are common in dense UI designs and that create real interaction difficulty for users with motor impairments. The criterion allows flexibility on spacing rather than requiring every target to be enlarged, which makes it more practical to achieve in existing designs.
- Audit focus handling across all interactive components and overlays so focused controls are not hidden by sticky or fixed-position content.
- Identify every drag-based interaction in your product and document the pointer-based alternative. If no alternative exists, it needs to be built.
- Check touch target sizes in components using icon-only controls, inline actions, and compact table rows. Spacing-based solutions are often more practical than enlarging the target itself.
- Review authentication and account recovery flows for password-manager support, paste support, and accessible alternatives to cognitive challenges.
- Update your accessibility acceptance criteria to include all four new WCAG 2.2 success criteria explicitly, with testable definitions for each.
TESTING_TOOLS_AND_THEIR_LIMITS
Automated accessibility testing tools catch a useful subset of conformance failures — typically around 30 to 40 percent of auditable issues — and are worth running in every CI pipeline. The tools most commonly used are axe-core (available as a browser extension, CLI, and testing library integration), Lighthouse, and WAVE. Each has different strength areas; running more than one catches a broader range of issues.
The failures automated tools reliably catch are missing alternative text, empty form labels, missing page titles, invalid ARIA usage, and some color contrast failures on static content. The failures they reliably miss are keyboard navigation flow problems, focus management errors in dynamic content (modals, drawers, notifications), screen reader announcement quality, and the contextual meaning of ambiguous controls. Those require manual testing, and they are consistently where the most serious accessibility failures sit.
Manual testing should cover: keyboard-only navigation through all primary user journeys, screen reader testing with at least two different screen reader and browser combinations (NVDA with Firefox, VoiceOver with Safari are the reference combinations for most European markets), and zoom testing at 200 percent with text size at the browser default. Those three test categories together surface the majority of failures that automated tools miss and that enforcement actions tend to focus on.
COLLECTING_EVIDENCE_FOR_ENFORCEMENT_READINESS
Under the EAA, the relevant evidence in an enforcement investigation is documentation that your organisation understood the requirements, built them into your delivery process, and can demonstrate what was tested and when. An accessibility statement published on the site is a required artefact under many national implementations, but it is a declaration, not evidence. The evidence is in the testing records — what was tested, by whom, with what tools, against which standard version, and what the results were.
The most defensible position is a testing record that updates with each significant release and covers both automated and manual test results. That record does not need to be elaborate. A structured document with the test date, the tester, the methodology, the scope, and the findings is sufficient. What makes it defensible is that it exists, is dated, and correlates with the actual delivery history of the product.