Skip to main content
Perceivly: Perceivly home
Log inStart free trial

Guides

Accessibility overlays: what they do, and why they don’t make a site accessible

What accessibility overlay widgets do, why they can’t make a website accessible or compliant, the FTC’s accessiBe order, and what to do instead.

By Perceivly team · Published · 9 min read

An accessibility overlay is a script you add to your website that promises to make it accessible automatically, often “with one line of code”. The pitch is attractive to a small business: no developer time, a monthly fee, and a badge that says the problem is handled. The problem is not handled. This guide explains what overlays actually do, why they can’t do what they promise, and what the evidence says, with sources you can check.

What an overlay is

You install an overlay by pasting a script tag into your site’s template:

<script src="https://cdn.overlay-vendor.example/widget.js" async></script>

Once the page loads in a visitor’s browser, the script does two kinds of things.

1. A toolbar

A floating button, usually with a wheelchair or person icon, opens a panel of settings: bigger text, higher contrast, a readable font, a larger cursor, highlighted links, stopped animations, and “profiles” such as “vision impaired” or “ADHD friendly”. Some add a built-in text-to-speech reader.

Almost all of this already exists in the browser and the operating system, where people who need it have set it up once for every site: browser zoom and minimum font size, Windows contrast themes, macOS and iOS “Increase contrast” and “Reduce motion”, reader modes, and screen readers such as JAWS, NVDA, VoiceOver and TalkBack. A person who needs larger text doesn’t want to find a different widget on each website. A blind person can’t find the widget without a screen reader in the first place.

2. Automatic “repairs”

The bigger promise is that the script detects and fixes WCAG problems in the page as it loads. Typical repairs: guessing alt text for images with image recognition, adding ARIA roles and labels to elements that look like buttons or menus, and adjusting colors. The vendor’s server may also store fixes that someone reviewed for your site.

These repairs happen in the visitor’s browser, after your page has loaded, on top of code that stays broken. That is where the trouble starts.

Why automatic repairs can’t make a site accessible

Many WCAG requirements need human judgment

A script can see that an image has no alt text. It can’t know why the image is on the page. Take a product photo on a shoe shop:

<!-- What image recognition guesses -->
<img src="IMG_4471.jpg" alt="a shoe on a white background">

<!-- What a shopper needs -->
<img src="IMG_4471.jpg" alt="Trail runner in navy with orange laces, side view">

The same goes for a chart (what is the trend it shows?), a video (what is said, and what happens on screen?), a form error (what exactly is wrong, and how do I fix it?), a heading structure (which text is a section title?), and the order in which a page makes sense. These are decisions about meaning, and they belong to whoever wrote the content. Our alt text guide shows how much the right answer depends on context.

Guessing at behavior breaks things

A common inaccessible pattern is a clickable <div>. An overlay can add a role and make it focusable:

<!-- Original -->
<div class="btn" onclick="addToCart(42)">Add to cart</div>

<!-- After an overlay "repair" -->
<div class="btn" onclick="addToCart(42)" role="button" tabindex="0">Add to cart</div>

Now a screen reader announces a button, and a keyboard user can tab to it. But pressing Enter or Space on it does nothing, because a <div> doesn’t fire a click from the keyboard. The page now claims to be accessible to the people it still fails. For a custom menu, a date picker or a modal dialog, the script would also have to know how each one is meant to behave: which keys open it, where focus goes, what closes it. It can’t.

Conflicts with the tools people already use

Screen readers and browser settings work on the page your site sends. A script that changes the page after load, or adds its own “screen reader mode”, can interfere with them. In interviews for a 2024 study of blind and low vision users, participants described overlay features clashing with their own screen readers, and the most common reason people gave for leaving a site was that it became less accessible after the overlay was added (Makati, Tigwell and Shinohara, ASSETS 2024).

The source stays broken

Your HTML, your CMS templates and your content don’t change. The same problems reach people when the script fails to load, is blocked, or runs late; in your emails and PDFs; in your mobile app; and on any new page you publish tomorrow. Fixing the source fixes it everywhere, once.

Conformance means every requirement, on every page

WCAG conformance is defined per full page: a page conforms at level AA only if it meets every level A and AA success criterion, including the ones that need judgment (WCAG 2.2, Conformance). No script can meet all of them. The Overlay Fact Sheet puts it plainly: “full compliance cannot be achieved with an overlay.”

What the evidence says

The FTC’s order against accessiBe (2025)

On January 3, 2025, the US Federal Trade Commission announced a complaint and proposed order against accessiBe, one of the largest overlay vendors (FTC press release). The FTC alleged that:

  • accessiBe misrepresented that its AI-powered widget, accessWidget, could make any website compliant with the Web Content Accessibility Guidelines, when it did not make all of its customers’ websites WCAG compliant;
  • it formatted third-party articles and reviews to look like independent opinions, and didn’t disclose its material connections to the supposedly impartial reviewers.

The order requires accessiBe to pay $1 million. It bars the company from claiming that its automated products can make any website WCAG compliant, or keep it compliant over time, without evidence to support the claim, and from presenting paid endorsements as independent. The Commission voted 5–0 to accept the proposed order and, after a public comment period, announced its approval of the final order on April 22, 2025, after a 3–0 vote (FTC press release). The FTC’s Bureau of Consumer Protection director said at the time that “overstating a product’s AI or other capabilities without adequate evidence is deceptive.”

The order is about one company’s advertising. It doesn’t say other overlays are better; it shows that the central promise of the category, “install this and your site is compliant”, was one a regulator found unsupported.

The Overlay Fact Sheet

The Overlay Fact Sheet is a public statement by accessibility practitioners, first published in 2021. When we checked it in November 2026 it listed more than 1,000 signatories. It says overlays don’t address the underlying problems, that their toolbars duplicate features users already have, that automatic repairs are unreliable, that “no overlay product on the market can cause a website to become fully compliant with any existing accessibility standard”, and that overlays raise privacy concerns because they can reveal that a visitor uses assistive technology. Its signatories ask site owners to fix accessibility at the source.

European disability organizations

On May 17, 2023, the European Disability Forum and the International Association of Accessibility Professionals issued a joint statement: “Overlays do not make the website accessible or compliant with European accessibility legislation. They do not constitute an acceptable alternative or a substitute for fixing the website itself.” They add that overlays “can interfere with the user’s assistive technology and override user settings” (EDF). If your business falls under the European Accessibility Act, that is the position of the people the law is meant to serve.

What users and practitioners report

  • In WebAIM’s 2021 survey of web accessibility practitioners (758 responses), 67% rated overlays, plugins or widgets as not at all or not very effective. Among respondents with disabilities it was 72%, and only 2.4% of them rated overlays as very effective (WebAIM).
  • In the ASSETS 2024 study, up to 42% of blind and low vision survey respondents said they had stopped using websites that had overlays (University of Washington summary).
  • In WebAIM’s 2024 survey of 1,539 screen reader users, 85.9% said more accessible websites would have a bigger impact than better assistive technology (WebAIM Screen Reader User Survey #10). People ask for sites that work, not for another tool.

Overlays don’t prevent lawsuits

Many overlays are sold on legal protection. UsableNet’s review of US digital accessibility lawsuits counted 5,114 filed in 2025 (data to December 15, 2025) and reported that “accessibility widgets did not slow litigation in 2025”: an increasing number of suits named companies already using these tools. Its monthly figures add up to more than 1,400 lawsuits against companies with a widget installed (UsableNet 2025 year-end report). Plaintiffs’ testers use screen readers and keyboards, and they meet the same broken code everyone else does.

Is there anything an overlay is good for?

Some people do find a contrast or text-size toggle handy, and a vendor’s scan may point you to real problems. But a site that is built well already respects the browser and system settings people rely on, and the problems a scan finds still have to be fixed in your code. If you like the idea of letting visitors choose a dark theme or larger text, build that into your site as a normal feature. It is not a substitute for meeting WCAG.

What to do instead

  1. Find the problems. Run an automated check on your key pages: the free checker tests one page against the automated WCAG 2.2 A and AA rules. Remember that automated tests catch only part of WCAG issues.
  2. Test the rest by hand. A keyboard pass, a zoom test and a short screen reader pass find most of what tools miss. Our accessibility checklist shows how, in priority order.
  3. Fix the source. Labels on form fields, names on icon buttons, real <button> elements, contrast in your theme, alt text in your CMS. Most fixes are made once in a template.
  4. Get an expert review of your most important flows, such as checkout or booking, if you need to show conformance to anyone.
  5. Keep watching. New content brings new problems. Check again on a schedule and track what you fix.
  6. Say where you stand. An honest accessibility statement, with known issues and a contact, does more for your visitors than a badge.

If you already have an overlay

  • Test your site with the overlay turned off. That is the site your source code delivers, and the one you have to fix.
  • Read your contract: what exactly does it promise, and when can you end it?
  • Make a fix plan for the problems you find, starting with checkout, forms and navigation.
  • Remove the script once the critical problems are fixed, and tell your users how to reach you if something doesn’t work.

Where Perceivly fits

Perceivly is not an overlay and adds nothing to your site. It checks your pages in a real browser on a schedule, tells your team what to fix in the code, and tracks each issue until the fix is live (monitoring). It helps you find and track issues; it doesn’t make a site compliant, and like every automated tool it covers only part of WCAG.

Sources