AI Won’t Save Your Overlay: Why the “Smarter Overlay” Is Still the Wrong Answer for Web Accessibility

The sales pitch has gotten a lot more polished.

Overlay vendors — the companies that sell JavaScript widgets promising to make your clients’ websites “instantly accessible” — have discovered that the word “AI” opens wallets in 2026. The major players now market their solutions as “powered by contextual AI” or “AI-powered remediation.” A growing number of second-tier vendors are racing to add machine learning features, real-time image alt-text generation, and “intelligent” color contrast adjustments to their offerings.

And to their credit, the demos look impressive.

But here’s what I’ve learned after 25 years in web development and a decade focused specifically on accessibility: the problem with overlays was never that they lacked AI. The problem is structural. And no amount of machine intelligence can fix a structural flaw.

What the Overlay Industry Is Selling (And Why It Works)

Let’s be honest about why overlays caught on in the first place.

Accessibility compliance is genuinely hard. WCAG 2.2 AA has 50+ success criteria. Remediating a large WordPress site can take months. The federal ADA Title II deadlines for state and local government websites are real (public entities under 50,000 population must comply by April 26, 2027), and your clients are panicking.

Into that anxiety steps an overlay vendor with a tagline like: “Achieve ADA compliance with one line of code.”

That’s an appealing message. It was appealing in 2018, and it’s still appealing now — just with “AI” added to the headline.

The core pitch of AI-powered overlays goes something like this:

Our system uses machine learning to automatically detect accessibility issues on your page and apply real-time fixes — adjusting contrast, adding missing alt text, making your menus keyboard-navigable — without any changes to your source code.

That last clause is the tell. Without any changes to your source code.

That’s not a feature. That’s the fundamental flaw.

The Structural Problem No AI Can Fix

To understand why AI can’t save overlays, you need to understand what an overlay actually does at a technical level.

An overlay is a JavaScript file that loads on top of your website in the user’s browser. It intercepts the page after the browser has already rendered it and attempts to modify what a user sees or what an assistive technology reads. It doesn’t touch your HTML. It doesn’t change your CSS. It doesn’t update your WordPress theme, your plugins, or your database.

It is, by design, a layer of runtime interpretation sitting between your real code and your users.

Here’s why that matters:

Screen readers don’t work the way overlay vendors think. Tools like JAWS, NVDA, and VoiceOver access the browser’s accessibility tree — a structured representation of the page built from your source HTML. Overlays attempt to manipulate that tree after the fact. But the timing, sequencing, and interpretation of that manipulation is unreliable across different screen reader and browser combinations. The result is often more confusion, not less.

The National Federation of the Blind has formally opposed overlay technology, stating that overlays “do not make websites accessible to blind users” and that their use “may create additional barriers.”

More than 700 accessibility professionals — including researchers, screen reader users, and WCAG contributors — have signed the Overlay Fact Sheet, explicitly stating that “overlay products… cannot achieve the level of conformance to WCAG 2.x that would be needed to ensure all people with disabilities can use a website.”

Now, none of that was written about AI overlays specifically. It was written about the generation of overlays that came before. And here’s the important question: Does adding AI change any of this?

What AI Overlays Actually Do (vs. What They Claim)

Let’s give the vendors their due. Some of the AI features being introduced are technically interesting. Here’s what’s actually happening under the hood:

AI-generated alt text: Some overlays now use computer vision models (similar to what powers Google Cloud Vision or Azure Cognitive Services) to analyze images on a page and generate descriptive alt text dynamically. This is real technology. It works sometimes.

But “works sometimes” is not “compliant.” AI-generated image descriptions frequently miss context, misidentify subjects, describe images literally rather than meaningfully, and fail entirely on charts, graphs, infographics, and anything with embedded text. WCAG 1.1.1 requires that alt text convey the purpose of an image in context — something that requires human judgment about what the image is communicating within a specific page.

AI-powered keyboard navigation: Some vendors claim their AI can “intelligently” make menus and interactive components keyboard-accessible. What they’re actually doing is injecting JavaScript focus management on top of your existing DOM. This creates conflict with the native focus order browsers already provide, can break custom JavaScript already on the page, and creates unpredictable behavior in complex components like modals, carousels, and data tables.

AI color contrast adjustment: Several overlays now claim to use AI to detect and fix low-contrast text. But WCAG 1.4.3 requires a 4.5:1 contrast ratio for normal text — and fixing this properly means changing your CSS. An overlay that overlays a semi-transparent mask or changes text color at runtime is modifying what sighted users see, but it may not be modifying what assistive technologies report. And it creates visual inconsistencies that can actually confuse users with cognitive disabilities.

The underlying problem: All of these AI features still operate at the presentation layer, not the structural layer. They are still JavaScript applied after page render. The fundamental architecture hasn’t changed. The AI is smarter window dressing on the same flawed foundation.

The Legal Record Is Already Being Written

For web agency owners, here’s where the conversation gets very practical.

If your client gets sued under the ADA — and lawsuit filings have topped 4,000 per year in recent years — their overlay is not going to protect them. The courts have begun to establish a clear record on this.

In Gomez v. Bang & Olufsen, the court found that an overlay did not render a website compliant with WCAG standards despite the vendor’s claims.

In Murphy v. Eyebobs, the defendant’s use of an overlay was found insufficient to dismiss an accessibility lawsuit. The court noted that real users with disabilities reported being unable to use the site despite the overlay being present.

The FTC has also taken notice. In recent years, the agency has scrutinized overlay vendors over deceptive marketing claims — specifically the claim that their products could make websites “fully ADA and WCAG compliant.”

The overlay industry’s response to this legal pressure has been telling: some vendors have begun bundling legal defense services with their subscriptions. Think about that for a moment. If your product worked, you wouldn’t need to sell insurance against lawsuits that your product was supposed to prevent.

As an agency owner, ask yourself: if your client gets sued and it comes out that you recommended an overlay solution — and that overlay vendor is simultaneously defending itself from federal claims about deceptive marketing — where does that leave your relationship with your client?

Why the Gap Between “AI Overlay” and “Real Accessibility” Is Wider Than It Looks

Here’s what genuine WCAG 2.2 AA compliance actually requires:

• Semantic HTML structure (headings, landmarks, lists, forms) written correctly at the code level
• Keyboard focus management that follows the user’s logical reading order
• ARIA attributes applied correctly and only where needed (incorrect ARIA is worse than no ARIA)
• Forms with associated labels, error identification, and meaningful instructions
• Videos with captions that are accurate, not auto-generated
• PDFs and downloadable documents that are separately remediated
• Dynamic content (modals, alerts, carousels, live regions) that communicates state changes to screen readers
• Color contrast that meets standards in your actual CSS, not patched at runtime

An AI overlay can gesture at some of these. It cannot reliably achieve them. And it cannot achieve them consistently across the combination of browsers, operating systems, screen readers, and zoom levels that real users rely on.

This is why the accessibility community’s position has remained consistent even as overlay technology has evolved: the gap isn’t about compute power or model sophistication. It’s about the fact that accessibility has to be built into a website, not applied over it.

The Department of Justice’s final rule implementing WCAG 2.1 AA for state and local government websites (published March 2024) makes no mention of overlay solutions as an acceptable compliance path. It explicitly references conformance testing against WCAG standards — which overlays routinely fail.

What We Saw at a Law Firm That Thought It Was Covered

I want to make this concrete, because abstract arguments about overlay architecture are easy to dismiss.

A few months ago, I was working with a law firm on an accessibility evaluation. Before we started, they let me know they weren’t especially concerned — they had a popular overlay installed and active on their site. They’d been told it handled compliance. They believed it.

We ran their homepage through Insi’s scanner. Here’s a partial list of what came back, with the overlay fully active:

• Empty buttons — interactive elements with no discernible label, completely invisible to screen readers
• Empty links — links with no meaningful destination text
• Content that should have been marked as headings but wasn’t, leaving the page with no navigable structure for keyboard or screen reader users
• Keyboard traps — places where a keyboard-only user could get stuck with no way forward

These aren’t obscure WCAG edge cases. They’re foundational failures. They’re also exactly the kind of issues that appear in ADA demand letters.

The overlay hadn’t touched any of them. What it had done was place a widget on the page that created the appearance of a compliance solution.

Seeing the actual findings changed the conversation entirely. The firm moved from “we’re covered” to “we need to understand what we actually have.” They installed Insi, began working with their development team on real fixes, and made plans to remove the overlay once the underlying issues were resolved.

This is the gap in practice, not just in theory. And it’s why the AI features being layered onto these products don’t change the fundamental answer: you cannot fix structural code problems with a script running on top of them.

What Agencies Should Be Doing Instead

I started Insi because I kept running into this problem. We had clients coming to us with overlays installed. The solution isn’t a smarter overlay. The solution is finding the real problems and fixing them.

Here’s the framework I’d recommend to any agency owner evaluating accessibility tools:

1. Start with a real scan that tests what real users experience. Most free scanning tools — Google Lighthouse, WAVE, and others — do static code analysis. They catch maybe 30–40% of WCAG issues because they’re reading your HTML, not rendering your page as a browser would. Dynamic issues — JavaScript-driven content, conditionally rendered components, user-triggered state changes — get missed entirely. Look for tools that use real browser rendering to test what a screen reader would actually encounter.

2. Get findings in a format your team can act on. A raw WCAG violation list is not actionable for most agency teams. You need findings organized by page, by component, by severity, with clear guidance on what fix is required. The goal is to route issues to developers who can fix them in the source code — not to mask them with a script.

3. Monitor continuously, not just at launch. Accessibility is a moving target. New content is added, plugins update, themes change. A one-time audit followed by an overlay is a false endpoint. You need ongoing monitoring that catches regressions before your client’s auditor — or their next plaintiff’s attorney — does.

4. Build this into your client contracts. Accessibility compliance is a billable, recurring service. Agencies that package accessibility monitoring with hosting and maintenance are seeing stronger client retention, higher monthly recurring revenue, and clients who are genuinely better protected. The agencies recommending overlays are solving the client’s immediate anxiety but creating a long-term liability for both of them.

A Direct Note on AI in Accessibility — Because It’s Not All Bad

I want to be precise here: the problem isn’t AI in accessibility. AI has genuine uses in this space.

AI can help developers write better semantic HTML. It can assist in drafting alt text that a human then reviews and refines. It can flag potential accessibility issues in design mockups before a line of code is written. It can help small teams that lack deep accessibility expertise understand what a WCAG failure means and how to approach fixing it.

These are legitimate, additive uses of AI — tools that help humans do better work.

What AI cannot do is replace the work. It cannot take a structurally inaccessible website and make it genuinely accessible by running a script on top of it. The physics of how assistive technologies work — reading the accessibility tree, interpreting focus order, announcing state changes — require that the underlying code be correct.

This is the distinction the overlay industry is deliberately blurring. They’re hoping that “AI-powered” sounds sophisticated enough that buyers won’t ask whether it actually works.

Your clients are trusting you to ask that question.

The Bottom Line for Agency Owners

The AI overlay is the accessibility industry’s equivalent of a weight loss pill. It promises a shortcut around work that doesn’t have shortcuts. And like weight loss pills, it’s most effective at generating revenue for the people selling it.

Here’s what I’d encourage you to take away:

• No overlay — AI-powered or otherwise — has been shown to reliably pass WCAG 2.1 or 2.2 AA conformance testing
• The legal record is increasingly clear that overlays do not provide meaningful protection against ADA litigation
• The AI features being added change the demo, not the architecture
• Real accessibility requires fixing source code, not patching it at runtime
• Agencies that build real accessibility into their service offering have a competitive advantage and a better client relationship

The ADA Title II deadlines are real. Your clients’ urgency is real. The temptation to hand them something that looks like a solution is understandable.

But your reputation — and theirs — is on the line. Make sure what you’re recommending actually works.