The EU AI Act and EAA — what the intersection means

The 2026 WebAIM Million report — the largest annual study of web accessibility — found that errors per page jumped 10.1% this year to an average of 56.1 errors per page, reversing six years of gradual improvement. Page complexity increased 22.5% in the same period. 95.9% of sites now fail basic accessibility checks. WebAIM linked the reversal directly to increased home page complexity and AI-assisted coding practices.

This is not a peripheral finding. WebAIM explicitly named AI-assisted development — what practitioners are calling ‘vibe coding’ — as a contributing factor in the degradation of accessibility across the web. The same tools being adopted at scale to accelerate development are, by default, shipping code that fails disabled users.

The AIMAC evidence base

The AIMAC benchmark (developed by the GAAD Foundation in partnership with ServiceNow) tested 36 AI coding models on their default accessibility output across 28 categories. The results are public at aimac.ai and updated as models change.

Most models produce non-compliant HTML by default. Not through negligence — accessibility has not been a primary training objective for any of them. The gap between the best and worst performing models is significant. Aaron Gustafson, presenting at Microsoft Build in June 2026, put the dynamic precisely: AI does not fix a broken process. It accelerates whatever process you already have. If accessibility is part of the workflow, AI can help scale inclusion. If it is not, AI will scale the barriers being shipped.

Anna E. Cook, in writing accompanying her FLUPA UX Days Paris keynote (June 2026), put the structural argument plainly: AI doesn’t fix accessible systems. It depends on them. Elsewhere in the same body of work she sharpened it further: a poorly designed system doesn’t get fixed by AI. It gets multiplied.

Research published in June 2026 by the University of Southampton, drawing on findings from 48 accessibility leaders, researchers and practitioners, found that verification demands from AI-generated content can double rather than reduce accessibility workloads. The assumption that automation improves accessibility is not evidenced. Ableist bias in AI is structural, rooted in training data, and resistant to technical fix.

What the EU AI Act requires

The EU AI Act applies to AI systems, not to all use of AI tools. The distinction matters. An organisation using an AI coding assistant to generate HTML is not automatically subject to the AI Act — the Act applies to AI systems that are placed on the market or put into service in the EU, where those systems meet the Act’s definition and risk classification.

Where the intersection with the EAA becomes significant is in two scenarios. First, where an organisation’s product includes an AI system within its scope — a recommendation engine, a chatbot, an automated decision system — and that product is covered by the EAA. Second, where AI coding tools are used in the development of EAA-covered products and their output is not reviewed against WCAG 2.1 Level AA before deployment.

For AI systems that fall within the Act’s scope and are embedded in EAA-covered products, the requirements include transparency obligations, human oversight mechanisms, and risk management processes. These do not substitute for EAA compliance — they apply in addition to it.

What EAA compliance requires

EAA compliance has four mandatory elements, regardless of how the product was built. Technical conformance with EN 301 549 (WCAG 2.1 Level AA). A published accessibility statement. Active governance — a named owner, a testing process, a mechanism for catching regressions. And documentary evidence of ongoing compliance management, not a one-off exercise.

“AI-generated” is not a defence. EN 301 549 does not distinguish between human-written and AI-generated code. It assesses the output. If the output is non-compliant, the product is non-compliant regardless of how the code was produced.

The AIMAC leaderboard provides a starting point: it identifies which models produce the least non-compliant code by default, and which require the most intensive review. That is not a compliance process — it is a starting point for knowing where to focus review effort.

The practical risk picture

For organisations building consumer-facing digital products with AI coding tools, the risk picture has three dimensions.

The overlay risk: AI-powered overlay tools are frequently marketed as accessibility solutions. They do not produce EAA compliance. Purchasing one creates a documented awareness record without addressing the underlying problem.

The development risk: if AI coding tools are generating non-compliant HTML by default and that code is reviewed against accessibility requirements before deployment, the process can work. If it is not reviewed, the accessibility debt accumulates silently — across every sprint, every release, every feature.

The intersecting framework risk: where an AI system is embedded in an EAA-covered product, both the EAA and the AI Act apply. The compliance requirements are different. Neither satisfies the other. The gap between them is not yet well mapped by most product teams — which is where the risk lives.

Enforcement in Ireland, the Netherlands, and Sweden is active. The penalty structures are material. The window for getting ahead of enforcement is narrowing.