Accessibility overlays don't make you compliant. Here's what does.

In April 2025 the FTC finalised a $1 million order against accessiBe, the market-leading accessibility overlay vendor, for falsely claiming its widget could make any website WCAG-compliant. This wasn't a one-off scandal, overlays have a structural technical limitation that means they cannot fix the underlying code issues that cause most real accessibility barriers, no matter how good the marketing is. UsableNet's 2024 data found roughly a quarter of all US web-accessibility lawsuits that year named a site that already had an overlay installed. Genuine compliance comes from testing your actual site by hand, keyboard and screen reader, and fixing the code itself, not from adding a layer on top of it.

What an overlay actually is

An accessibility overlay (sometimes called a widget or plugin) is a small piece of JavaScript you add to your site, usually with a single line of code. It sits on top of your existing pages and tries to adjust things on the fly, resizing text, tweaking colour contrast, adding labels it guesses at, changing how some elements behave. The pitch is simple and appealing: install one script, and your whole site becomes accessible.

That pitch is what got accessiBe, the largest vendor in this space, a $1 million bill from the US Federal Trade Commission.

The FTC's case against accessiBe

The FTC's Bureau of Consumer Protection investigated accessiBe over claims that its accessWidget product could make any website compliant with WCAG. Its complaint, filed in January 2025, alleged those claims were false, misleading, or unsubstantiated. Samuel Levine, Director of the FTC's Bureau of Consumer Protection, put it plainly at the time:

"Companies looking for help making their websites WCAG compliant must be able to trust that products do what they are advertised to do. Overstating a product's AI or other capabilities without adequate evidence is deceptive, and the FTC will act to stop it."

On 21 April 2025, the FTC approved the order as final. It requires accessiBe to pay $1 million and permanently bars the company from representing that its automated products can make any website WCAG-compliant, or can keep a website compliant over time, unless it actually has the evidence to back that up.

The order goes further than the headline claim, too. The FTC's complaint also alleged that accessiBe formatted third-party articles and reviews to look like independent opinions, without disclosing its financial ties to the people writing them. The final order separately bars accessiBe from misrepresenting that reviews, blog posts or endorsements about its products are independent when they aren't, or that an endorser is an ordinary, unaffiliated user when they're not.

This matters beyond one company. accessiBe was the category leader, if the flagship product in this space couldn't substantiate its central compliance claim to a federal regulator, that's a meaningful signal about what the entire product category can and can't actually deliver.

Why overlays fail: the technical reason, in plain English

This isn't really a story about one company cutting corners. It's about what an overlay technically can and can't do, by design.

Your website's accessibility problems live in its underlying code, the HTML, CSS and JavaScript that a browser and a screen reader actually read. Common real problems include:

• A button that's coded as a plain <div> instead of an actual button, so a screen reader has no idea it's clickable
• A form field with no label attached in the code, so a screen reader announces it as "edit text, blank" with no clue what it's for
• A navigation menu that can't be opened, closed or moved through using only a keyboard
• Headings that skip levels or aren't marked up as headings at all, so a screen reader user can't jump around the page the way it's designed for

An overlay sits on top of this code, as a script running after the page has already loaded. It can change what things look like, bigger text, a different colour, a widget button in the corner, but it generally cannot rewrite the fundamental way an element is built and exposed to assistive technology. It can't retroactively turn a <div> into a real, properly-labelled button in the way a screen reader needs. It can't reliably fix keyboard navigation that was never built to work without a mouse. It's adjusting the surface of a page whose actual structure is unchanged underneath.

That's the core problem: most of the accessibility issues that actually block a disabled customer are structural, and overlays operate above the structure, not inside it. A widget can offer a "screen reader mode" as an alternative interface, but that isn't the same as making your actual site work with the screen readers real disabled users already have installed and already know how to use, and many disabled users, understandably, don't want a separate, vendor-controlled alternative experience; they want the site itself to work.

The scale of the problem

This isn't a fringe concern. According to UsableNet's 2024 Year-End Digital Accessibility Lawsuit Report, as widely reported, roughly 25% of all US web-accessibility lawsuits filed in 2024, 1,023 cases, named a site that already had an accessibility overlay or widget installed at the time. Put differently: having an overlay installed did not stop those businesses being sued, and in a meaningful share of cases the lawsuit specifically cited the overlay as a barrier rather than a fix.

That figure comes from UsableNet's litigation tracking (as reported by industry outlets covering the year-end report) rather than something Accessimo has independently verified line by line, but it's consistent with the wider pattern accessibility practitioners have been describing for years, and now with what the FTC itself found in accessiBe's case specifically.

The accessibility community's own verdict

This isn't just regulators and lawsuits. The accessibility profession itself has been saying this for years. The Overlay Fact Sheet (overlayfactsheet.com) is an open letter, first published in 2021, stating plainly that overlays do not fix the underlying problems with inaccessible websites. As of 2026, it has been signed by more than 800 accessibility practitioners, developers, and disability advocates, including signatories with direct professional ties to organisations like Google, Microsoft, the W3C, and Shopify, among many independent consultants and disabled testers themselves. One signatory, Matt King, chairs the W3C's ARIA Authoring Practices Task Force, one of the bodies that literally writes the technical standards overlays claim to help you meet.

When the people who write the accessibility standards, and the people who use assistive technology every day, agree that a category of product doesn't do what it says, that's not a minor disagreement about marketing tone.

Overlay vs manual testing and remediation

What genuine remediation actually looks like

There's no shortcut here, and we won't pretend there is one. Real accessibility work looks like this:

• Automated scan first, fast, useful for catching surface-level issues like missing alt text and contrast failures, but only ever a starting point.
• Manual keyboard-only testing, tabbing through the actual site with no mouse, on the homepage, a category page, a product page, cart, and checkout, to see what a keyboard-only user genuinely experiences.
• Manual screen reader testing, the same journey again using NVDA, a free screen reader commonly used for UK compliance testing, listening to what's actually announced rather than assuming the code is right.
• A severity-rated findings report, what's broken, how badly, and what needs to change, written for a developer to act on.
• Actual code fixes, either your developer implements them, or, with our Managed monitoring, we fix a capped number of hours of issues directly in your code each year.
• Ongoing monitoring, because sites change constantly (new products, new pages, redesigns, third-party app updates), and a site that was accessible last quarter can quietly stop being accessible this quarter without anyone touching the accessibility-specific code at all.

This is exactly the process we ran on our own site, and on every client audit we've published as a case study, including a checkout where a payment method was completely unreachable by keyboard, something no automated scan or overlay would ever have caught.

Not sure where your site stands right now?

Frequently asked questions

Are all accessibility overlays exactly the same as accessiBe?

Not identically, but the core technical limitation applies to the category as a whole, not to one vendor. Every overlay works by adjusting a page after it loads, from outside the underlying code, that's the defining feature of the product type, not something specific to accessiBe. The FTC's action was against accessiBe specifically, but the reasoning behind why overlays struggle to deliver genuine compliance applies more broadly.

Is it illegal to use an accessibility overlay?

No. Installing an overlay isn't itself unlawful. The legal risk is that an overlay doesn't reliably make your underlying site accessible, so it doesn't remove the compliance gap that laws like the UK Equality Act and the EAA are concerned with, and, per the lawsuit data above, its presence has sometimes been cited as evidence a business tried a superficial fix rather than a real one.

Can an overlay be useful for anything?

Some overlays include genuinely helpful, cosmetic-level options, larger text, adjustable colour themes, that some users appreciate. The issue is specifically the claim that installing one makes a site "compliant" or "accessible," which the evidence above doesn't support for the structural issues that matter most.

If I already have an overlay installed, should I remove it before an audit?

Not necessarily before the audit, a manual audit tests your actual site and will identify issues regardless. But don't treat the overlay's presence as reducing what needs fixing; treat the audit findings as the real list, independent of whatever the overlay claims to be handling.

How is Accessimo's audit different from what an overlay vendor offers?

We don't sell a script that sits on top of your site. We manually test your actual site with a keyboard and NVDA, deliver a specific, severity-rated findings report, and, through our Managed monitoring, fix real issues directly in your code. Nothing we do is automated-only, and nothing we report is guessed at by an algorithm.