The EU AI Act and EAA — what the intersection means

The 2026 WebAIM Million report is the largest annual study of web accessibility. It 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, such as a recommendation engine, a chatbot or 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. That is where the risk lives.

The AI Act timeline has since moved, and it is worth being precise about what did and did not change. The Digital Omnibus on AI, Regulation (EU) 2026/1744, adopted by Parliament on 16 June 2026 and the Council on 29 June 2026, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, defers the AI Act’s high-risk obligations. Stand-alone high-risk systems under Annex III now apply from 2 December 2027 rather than 2 August 2026, and high-risk AI embedded in regulated products under Annex I from 2 August 2028.

What was not deferred is the transparency set. The Article 50 obligations, including the duty to tell people they are interacting with an AI system, applied from 2 August 2026 as originally planned, with the Article 50(2) marking and detection requirements for systems already on the market following on 2 December 2026. This is a deferral of one track, not a weakening of the Act: the obligations themselves are unchanged, the conformity assessments and technical documentation are still coming, and the deferral was granted because the harmonised standards were not ready, not because the requirements were reconsidered.

For accessibility the practical point is unaffected. The change moves the timeline for Article 16(1)(l), the requirement that high-risk AI systems comply with existing EU law including the EAA, but it does not change the EAA obligation itself. Organisations whose AI systems interact with EU consumers are subject to EAA enforcement now, regardless of when the AI Act’s high-risk obligations take effect. The deferral does not create a window; it removes an argument for urgency on one track while the other remains active.

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