Do Accessibility Overlays Work? We Tested 62 Websites

No, not as a way to make a website accessible or compliant. We tested 62 websites that run an accessibility overlay, measuring each one with axe-core twice: once with the overlay running and once with its scripts blocked. On 90% of the sites, the overlay made no measurable difference to WCAG violations. 93.5% of overlay sites still failed at least one WCAG rule with the overlay active, which is slightly worse than the 87.7% we measured across a general sample of 219 homepages.

Overlays did change something on a few sites. One patched a batch of unlabeled form fields at runtime. A few others introduced new violations through their own toolbar buttons. None of them fixed the most common failure on the web, color contrast.

This article explains what overlays are, how we tested them, what the data shows rule by rule, why the architecture limits what any overlay can do, and what to do instead. It also includes the script we used, so you can test the overlay on your own site.

What an Accessibility Overlay Is

An accessibility overlay is a third-party JavaScript widget added to a site with a single <script> tag. It usually offers two things:

1. A toolbar (often a floating person icon) that lets visitors enlarge text, change contrast, pause animations or switch fonts.
2. Automatic remediation, marketed in some cases as AI, which rewrites the page's DOM after it loads: adding ARIA attributes, generating alt text, labelling fields.

The pitch is compliance without changing your code. That's the claim our test checks: if an overlay fixes accessibility problems automatically, an automated accessibility engine should find fewer of them with the overlay running.

How We Tested

Vendors among the 62 measured sites: UserWay 27, accessiBe 22, EqualWeb 7, AccessiWay 3, and one each for AudioEye, Eye-Able, Recite Me and Max Access. Measurements were taken on 3 October 2026.

⚠️ What this does and doesn't test. axe-core measures what a machine can verify in the DOM, so this is a fair test of "does the overlay remove detectable WCAG failures?" It doesn't test the toolbar's display options, and it can't capture problems overlays may cause for screen reader users, which have to be tested by hand.

The Results

Page content changes between loads (ads, carousels, personalised blocks), so a raw on-vs-blocked difference isn't automatically caused by the overlay. Our control run loaded each page a second time with the overlay on. Where two overlay-on runs disagreed with each other, the variation came from the page, not the widget.

After accounting for that noise, across the 60 sites with a control run:

By rule, summed across all 62 sites:

The small "on" advantage in color-contrast and target-size comes almost entirely from two near-identical news sites. Their second overlay-on run matched the blocked run exactly, so that difference was rotating content, not the overlay.

The genuine improvements were concentrated where an overlay can act on its own: adding accessible names to unlabeled form fields and links. That's real, but narrow, and it's the easiest category to fix properly in your own HTML.

Why Overlays Can't Fix Most Accessibility Problems

They run after your page, not instead of it. An overlay patches the DOM after it has loaded. Anything in your components' behaviour stays as it is: keyboard traps, focus that disappears into a modal, a custom dropdown that ignores arrow keys, a form that clears itself on error.

They can't know what your content means. An overlay can add alt="image" or a machine-generated caption. It can't know that the chart shows revenue doubled in Q3, or that the photo is your CEO. Accurate alt text, link purpose and error messages need someone who knows the page.

They don't fix contrast in your default design. The toolbar's high-contrast mode is opt-in. Every visitor who doesn't find and enable it, which is almost everyone, still gets your original colours. That's why contrast failures were essentially identical with or without the overlay.

People with disabilities already have tools. Screen readers, OS-level zoom and contrast settings, and browser extensions are configured once and used everywhere. A per-site toolbar duplicates them, and DOM rewrites can conflict with them.

Audits and complaints test your site. Accessibility auditors and plaintiffs' experts test the experience with assistive technology, not your widget settings. Litigation trackers have documented lawsuits filed against sites that already had an overlay installed.

What the three improvements tell you

The three sites where an overlay did reduce violations are worth a closer look, because they show the ceiling of the approach. In every case, the overlay added a missing accessible name: a label on a form field, text for an icon link or button. Those are DOM properties a script can set without understanding the page.

Even there, the fix is fragile. A generated name like "button" or "link" passes axe-core's presence check but tells a screen reader user nothing. The names exist only for visitors whose browser successfully downloads and runs the third-party script. And they vanish the moment the vendor's code changes, the contract lapses, or a content blocker strips the widget. The same label written into your HTML costs one line and never expires.

The Regulatory and Community Position

• In January 2025, the US Federal Trade Commission announced an order requiring the overlay vendor accessiBe to pay $1 million. The FTC alleged that the company misrepresented its AI tool's ability to make websites WCAG-compliant, and that it presented paid reviews as independent.
• The Overlay Fact Sheet, signed by hundreds of accessibility practitioners, including many disabled users, advises against relying on overlays and asks vendors to stop claiming that they ensure compliance.
• WCAG itself is about the content and code you publish. The WCAG 2.2 standard has no concept of a widget making non-conforming content conform.

None of this means every overlay feature is useless. Some people like a text-size or reading-mask control. It means an overlay is, at best, a convenience add-on, never a compliance strategy.

Questions to Ask Before You Buy or Renew an Overlay

If you're evaluating a vendor, or renewing one, these questions separate marketing from measurable outcomes:

1. "What percentage of WCAG 2.2 AA success criteria does your product fully remediate without code changes?" Ask for the list, criterion by criterion.
2. "Will you show me an axe-core report of my site with your script blocked and with it running?" That's the test in this article. A vendor confident in its product should welcome it.
3. "How do you fix keyboard traps, focus order and custom widget behaviour?" These live in your JavaScript, not your markup.
4. "Where does generated alt text come from, and who reviews it?"
5. "What happens to accessibility on my site if the script fails to load?" The answer should be "nothing changes", and that's the point.
6. "Do you indemnify us if we're sued?" Read the actual contract terms, not the sales page.

Test the Overlay on Your Own Site

This script detects known overlay vendors on each URL, runs axe-core with the overlay active and with it blocked, and prints the violation counts side by side. Run it twice if the numbers differ, since pages with rotating content vary from load to load.

#!/usr/bin/env python3
"""Does this site run an accessibility overlay — and what does it change?

For each URL: detects overlay widgets by their script hosts, then runs axe-core twice
in Chromium — once as visitors see it (overlay active) and once with the overlay's
hosts blocked — and prints the violation counts side by side.

Usage:  pip install playwright && playwright install chromium
        python3 overlay_check.py https://example.com https://another.example
"""
import asyncio, sys
from urllib.parse import urlsplit
from playwright.async_api import async_playwright

AXE_CDN = "https://cdnjs.cloudflare.com/ajax/libs/axe-core/4.10.2/axe.min.js"
VENDORS = {"accessiBe": ["acsbapp.com", "acsbap.com", "accessibe.com"], "UserWay": ["userway.org"],
           "AudioEye": ["audioeye.com"], "EqualWeb": ["equalweb.com", "nagich.co"],
           "Recite Me": ["reciteme.com"], "Eye-Able": ["eye-able.com", "eye-able-cdn.com"],
           "AccessiWay": ["accessiway.com"], "Max Access": ["maxaccess.io"], "Allyable": ["allyable.com"]}
HOSTS = [h for hs in VENDORS.values() for h in hs]


async def audit(browser, url, block):
    ctx = await browser.new_context(viewport={"width": 1366, "height": 900}, bypass_csp=True)
    seen = set()

    async def route(r):
        host = urlsplit(r.request.url).hostname or ""
        hit = next((v for v, hs in VENDORS.items() if any(host == h or host.endswith("." + h) for h in hs)), None)
        if hit:
            seen.add(hit)
            if block:
                return await r.abort()
        await r.continue_()
    await ctx.route("**/*", route)
    page = await ctx.new_page()
    resp = await page.goto(url, wait_until="load")
    if resp and resp.status >= 400:
        await ctx.close()
        raise RuntimeError(f"HTTP {resp.status} — the site blocks headless browsers; audit it manually")
    await page.wait_for_timeout(7000)              # overlays inject after the load event
    await page.add_script_tag(url=AXE_CDN)
    v = await page.evaluate("""async () => (await axe.run(document, {runOnly: {type: 'tag',
        values: ['wcag2a','wcag2aa','wcag21a','wcag21aa','wcag22aa']}})).violations
        .map(x => [x.id, x.nodes.length])""")
    await ctx.close()
    return seen, dict(v)


async def main(urls):
    async with async_playwright() as pw:
        browser = await pw.chromium.launch()
        for url in urls:
            try:
                vendors, on = await audit(browser, url, block=False)
            except RuntimeError as e:
                print(f"{url}: {e}\n"); continue
            if not vendors:
                print(f"{url}: no known overlay detected\n"); continue
            _, off = await audit(browser, url, block=True)
            print(f"{url}: overlay = {', '.join(sorted(vendors))}")
            print(f"  {'rule':28} {'overlay ON':>10} {'overlay OFF':>12}")
            for rule in sorted(set(on) | set(off), key=lambda r: -max(on.get(r, 0), off.get(r, 0))):
                print(f"  {rule:28} {on.get(rule, 0):>10} {off.get(rule, 0):>12}")
            print(f"  {'TOTAL elements':28} {sum(on.values()):>10} {sum(off.values()):>12}\n")
        await browser.close()


if __name__ == "__main__":
    asyncio.run(main(sys.argv[1:]))

Typical output for an overlay site in our sample, here a university homepage running an accessiBe widget:

overlay = accessiBe
  rule                         overlay ON  overlay OFF
  link-name                            51           51
  button-name                           5            5
  target-size                           4            4
  color-contrast                        2            2
  meta-viewport                         1            1
  TOTAL elements                       63           63

Fifty-one unnamed links, with or without the overlay. Every one of them is a one-line HTML fix.

What to Do Instead

1. Run an automated audit of your key templates to clear the machine-detectable failures: contrast, names, alt text, labels, zoom and target size. That's the majority of what overlays claim to handle. Our guide to what automated accessibility testing catches explains where that stops.
2. Fix them in your source code, in shared components and design tokens, so the fix applies everywhere and survives redesigns. Start with the most common WCAG violations and color contrast errors.
3. Test manually with keyboard and a screen reader on each template: navigation, forms, modals, checkout.
4. Publish an accessibility statement with a working contact route, and fix what users report.
5. Re-test on a schedule, because every release can reintroduce problems.

If an overlay is already installed, you don't need to rip it out today. Just don't count it as remediation. Measure your site with it blocked: that's the version your code actually ships. For the legal side, our guide on checking ADA website compliance covers what auditors look at.

How BugViso Helps You Fix the Source

BugViso runs a self-hosted axe-core engine with the WCAG 2.0, 2.1 and 2.2 A/AA rule tags on every audited page, in a real Chromium render. It reports each violation with its rule, WCAG criterion, impact and the exact failing elements. For contrast, it shows the measured colors and ratio. A mobile emulation pass adds tap-target sizing against WCAG 2.5.8.

BugViso isn't an overlay and doesn't inject anything into your site. It tells you what to change in your code. Each finding comes with a fix in the remediation playbook, and in the PDF report you can hand to developers. Scheduled weekly or monthly scans catch regressions before users do. To see what your site looks like without any widget, run a free BugViso accessibility scan.

FAQ

Do accessibility overlays make a website ADA compliant?

No overlay can guarantee compliance. In our test, 93.5% of overlay sites still had detectable WCAG violations with the overlay running, and most accessibility requirements, such as keyboard operation, meaningful alt text and error handling, can't be fixed by a script that runs after the page loads. This isn't legal advice; consult a lawyer for compliance decisions.

Are accessibility overlays bad?

The toolbar features are mostly harmless conveniences. The harm comes from treating the overlay as a fix, which leaves real barriers in place. Some overlays also add their own accessibility problems: on 5% of the sites we tested, the widget introduced new violations.

How common are accessibility overlays?

In our sample of 5,147 readable homepages from the Tranco top 50,000, 1.4% loaded a known overlay. UserWay and accessiBe accounted for most of them.

Can I keep my overlay and still fix my site properly?

Yes. Fix your code as if the overlay didn't exist, and test with it blocked. Many teams remove the overlay once their own remediation is done, because it no longer adds anything users need.

Did any overlay improve the results?

On 3 of the 60 sites with a control run, yes, by adding names to unlabeled form fields and links at runtime. The same fixes take minutes in HTML and then work for every user and every tool, including the ones that never execute the overlay's script.

Conclusion

On 90% of the sites we tested, the overlay changed nothing an accessibility engine could measure, and it never fixed contrast, the web's most common failure. Fix the source instead, starting with the list a BugViso accessibility scan gives you.