The AI accessibility paradox — overlays vs genuine compliance

Two things are happening simultaneously in the AI and accessibility space. AI coding tools are generating non-compliant HTML by default, creating a continuous stream of accessibility failures in products built with AI assistance. And a separate category of AI-powered tools — overlay products — is being sold as the solution to exactly that problem.

Aaron Gustafson, presenting at Microsoft Build in June 2026 alongside Jessie Lorenz, a blind PM at Microsoft, and GitHub’s Carie Fisher, framed the underlying 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 accelerate and scale the barriers being shipped. That is the paradox — and overlay tools sit squarely on the wrong side of it.

One line of JavaScript. Instant compliance. No development work required. That is the claim. It is worth examining carefully.

What overlay tools claim to do

Accessibility overlay tools are JavaScript libraries that load on top of a website or application and apply automated modifications to the underlying page. They typically include features such as contrast adjustment, text resizing, keyboard navigation aids, and screen reader compatibility fixes — all delivered without changes to the underlying HTML.

The marketing for these tools routinely promises EAA compliance, WCAG conformance, or immediate accessibility for all users. Some overlay vendors claim that a single line of code is sufficient to meet legal accessibility obligations. The price point is attractive. The promise is significant.

What the evidence shows

The evidence does not support the claims. Screen reader users and keyboard users — the people these tools most directly claim to help — consistently report that overlay tools make their experience worse, not better. The automated modifications interfere with the assistive technology the user is already using. The result is more barriers, not fewer.

This is not a fringe view. The National Federation of the Blind and the American Council of the Blind have both formally opposed overlay tools. Hundreds of accessibility practitioners and researchers have signed the Overlay Fact Sheet, a public statement of opposition based on evidence from disabled users and technical analysis. The practitioner consensus on overlay tools is clear.

In January 2025, the US Federal Trade Commission ordered an overlay vendor to pay $1 million for deceptive claims that its AI product could make websites accessible. EAA enforcement in Europe has not yet produced equivalent decisions, but the direction of travel is clear.

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 same research found that the assumption automation improves accessibility is not evidenced — and that ableist bias in AI is structural, rooted in training data, and resistant to technical fix. Overlay tools represent precisely the kind of automated response this research identifies as insufficient: a technical layer applied on top of a structural problem.

Research presented at Microsoft Build in June 2026 found that out of the box, most AI coding agents only pass around 8–25% of automatable accessibility checks. Even with instruction files guiding the model, the pass rate only reaches 37–60%. The implication is direct: AI tools are generating inaccessible code at scale, and overlays applied on top of that code do not resolve the underlying failures.

The technical reason is straightforward. Overlay tools add a layer on top of inaccessible code rather than fixing the underlying HTML. A form label that is missing from the source code cannot be reliably inferred and inserted by a JavaScript overlay. A keyboard trap in the underlying navigation cannot be resolved by a script running on top of it. The source of the problem and the proposed fix are operating at different levels.

The EAA position

An overlay tool does not constitute EAA compliance. EN 301 549 — the harmonised European accessibility standard referenced by the EAA — requires conformance with WCAG 2.1 Level AA. Conformance is measured against the underlying HTML, not against a JavaScript layer applied on top of it.

Enforcement bodies assess the product as a user experiences it, particularly as a disabled user with assistive technology experiences it. An overlay that makes that experience worse does not bring the product closer to conformance. It moves it further away.

“Our AI wrote it” is not a compliance defence. Neither is “we installed an overlay.” The obligation attaches to the output — to what a disabled user encounters when they try to use the product.

The commercial risk of documented non-compliance

There is a specific risk attached to purchasing an overlay tool in the belief that it provides compliance. The purchase creates a documentary record: the organisation was aware of its EAA accessibility obligations, and it chose a response. If that response is subsequently found to be insufficient — which the evidence strongly suggests it will be — the organisation has documented its awareness without having addressed the problem.

In Ireland, where directors face personal criminal liability for EAA non-compliance, the due diligence defence requires evidence of active, genuine compliance management. A documented decision to install an overlay rather than undertake technical remediation is unlikely to constitute due diligence.

No EAA fines have been issued in any market as of June 2026. But enforcement is active. When penalty decisions arrive, the organisations with documented awareness and insufficient responses will be in a weaker position than those that took no action at all — because they have already demonstrated they knew.

What genuine compliance requires

There is no shortcut. Genuine EAA compliance requires the same things it always has.

Technical remediation of the underlying code: fixing the HTML, the ARIA, the keyboard interactions, the colour contrast, the form labels — in the source, not in a layer on top of it. This is the work that overlays claim to replace. It cannot be replaced.

A published accessibility statement that accurately reflects the current state of the product, identifies what is not yet accessible, and includes a remediation plan. A statement that claims full compliance through an overlay does not meet this requirement.

Active governance: a named owner for accessibility, a testing process, and a mechanism for catching regressions before they reach production. AI-assisted development makes this more important, not less — the pace of code generation means accessibility failures can accumulate between review cycles if there is no process to catch them.

Documentary evidence of active management: dated assessments, remediation records, and a process trail that demonstrates ongoing attention, not a one-off exercise.

None of these can be purchased as a one-line JavaScript include. Digital accessibility is a property of the product, not a feature added on top of it.