Do Accessibility Overlays Actually Make a Site Accessible?

Do Accessibility Overlays Actually Make a Site Accessible?

No. An overlay is a script that adjusts a page after it loads, and it cannot fix the structural problems that block most disabled users. In January 2025 the Federal Trade Commission ordered one of the best known overlay vendors to pay a million dollars over claims that its tool made websites compliant.

This comes up when somebody senior gets an email warning about accessibility lawsuits and finds a product promising compliance for a monthly fee and one line of JavaScript.

We understand the appeal. The honest position is that the offer is not what it appears to be, and the regulator has now said so in writing.

What Is an Overlay, Exactly?

A third-party script you add to your site that tries to detect and patch accessibility problems in the browser, plus a floating button that opens a panel of settings such as larger text, higher contrast or a reading guide.

Two different things are bundled together there, and keeping them separate makes the whole debate clearer. The settings panel is a user preference toolbar. The automatic remediation is a claim that software can infer and repair meaning your markup never carried.

The toolbar part is mostly harmless and mostly redundant, because operating systems and browsers already offer text scaling, contrast and zoom, and disabled users generally have those configured the way they want. The automatic remediation part is where the claims get expensive.

What Did the FTC Actually Find?

The Commission's press release of 3 January 2025 says it alleged that accessiBe misrepresented the ability of its AI-powered web accessibility tool to make any website compliant with the Web Content Accessibility Guidelines. The complaint stated plainly that accessWidget did not make all user websites WCAG-compliant and that these claims were therefore false, misleading, or unsubstantiated.

The order requires a one million dollar payment and bars the company from representing that its automated products, including accessWidget's AI, can make any website WCAG-compliant or ensure continued compliance over time, unless it has evidence to support the claim.

There was a second finding that gets less attention and deserves more. The FTC said the company deceptively formatted third-party articles and reviews to look like independent opinions by impartial authors, without disclosing its material connections to those reviewers. If your evaluation of overlays came from positive articles you found by searching, that finding is about the thing you read.

Why Do Overlays Keep Selling Anyway?

Because they are sold against fear, priced against a lawsuit, and bought by people who are not the ones who will use the site. A monthly fee that makes a frightening problem disappear is a very easy purchase to approve.

They also sell because the alternative sounds worse. Real remediation means auditing templates, fixing markup, retraining a content team, and accepting that accessibility is ongoing work rather than a purchase. Nobody enjoys presenting that to a budget holder.

In our experience the decision is almost never made by anyone who has watched a real person use a screen reader on the site. That single observation changes the conversation faster than any argument, and it is the thing we push for first.

How Bad Is the Underlying Problem?

Bad, and getting worse rather than better. WebAIM's 2026 analysis of the top one million home pages, run in February 2026, detected WCAG 2 failures on 95.9 percent of them, up from 94.8 percent the year before.

The scale is the striking part. That analysis found 56,114,377 distinct accessibility errors, an average of 56.1 per page, which is 10.1 percent worse than 2025. Six failure types accounted for 96 percent of everything detected.

Those six are worth naming because they tell you where the work is. Low contrast text appeared on 83.9 percent of pages, missing alternative text on 53.1 percent, missing form input labels on 51 percent, empty links on 46.3 percent, empty buttons on 30.6 percent and missing document language on 13.5 percent.

Read that list again and ask which of them a script could honestly repair from the outside. It can guess at an image's meaning. It cannot know what your button does or what your link leads to. It can restyle contrast and break your brand while doing it.

Does an Overlay Reduce Your Legal Risk?

We are a web studio and not your lawyers, so take that seriously rather than as a formality. What we can point at is the regulator's own language, and it runs the other way. The order specifically bars claims that the automated product can make a site compliant or keep it compliant over time without evidence.

A product the FTC has ordered to stop claiming compliance is a strange foundation for a compliance position. And the failures listed above remain in your markup whether or not a script is patching them at runtime, which means anyone who audits your site properly will still find them.

If you are working to a legal deadline, get advice from someone qualified about your specific obligations, and treat the technical work as separate from the legal question. Our overview of the standards themselves is in our guide to WCAG.

What Would Fix Most of It Instead?

The same six things, fixed properly in your templates. Contrast is a design system decision made once and applied everywhere. Form labels, honest link text and non-empty buttons are markup, and they are usually fixed in a handful of components rather than on hundreds of pages.

Alternative text is the one that needs people rather than code, because it needs someone who knows what the image is for. That is a content process, and building it into how images get uploaded is the difference between fixing it once and fixing it forever.

The reason this works is that most sites are a small number of templates wearing a large number of URLs. Fix the component, fix every page that uses it. That is why we start every accessibility engagement by auditing templates rather than pages.

Automated tooling genuinely helps here, as long as you know its limits, and we covered those in what you can actually automate in accessibility testing.

Is There Any Case for a Widget at All?

A narrow one. If you build your own preference controls, tied to your own design tokens, and they do something your site specifically needs, that can be a genuine feature. A reading-focus mode on a long report, or a density control on a data-heavy tool, can earn their place.

The difference is that you own the behaviour, it is tested, and it does not claim to be compliance. It is a feature for everyone, not a patch layered over unfixed markup.

What we would not do is add a third-party script that modifies the DOM at runtime and sits between your content and assistive technology. That is a lot of risk to accept for a button in the corner.

What Should You Do if You Already Have One Installed?

Do not rip it out on Monday morning. Removing it before anything replaces it can make things worse for people currently relying on some part of it, and it turns a technical decision into a support incident.

Instead, get a baseline first. Run an audit with the overlay disabled so you can see the real state of the markup, which is what an auditor or a complainant would see anyway. That gives you the actual list of work.

Then fix the template-level failures, test with real assistive technology, and remove the script once the site stands on its own. Testing properly is a skill worth building in-house, and we wrote about how to start in testing a site with a screen reader.

What Do We Tell Clients Who Ask?

That the overlay is not the shortcut it looks like, and that the real work is smaller than they fear. Most of what WebAIM found across a million pages is six fixable categories, concentrated in a handful of components, and a lot of it is caught in a first pass.

We also tell them the uncomfortable part. Accessibility is not a project that finishes. Every new template, every content upload, every third-party embed is a chance to reintroduce a problem you already fixed. A script does not change that, and neither does a certificate.

If you have inherited a site with an overlay on it and want an honest read on what is underneath, that is a conversation we have regularly and are glad to have. Come and find us at phoenix.studio.