Accessibility overlays vs fixing the source: an honest look

If you’ve looked into web accessibility, you’ve seen the pitch: add one line of JavaScript and an AI “makes your site compliant”. These products are usually called overlays. They’re popular, they’re controversial, and we sell something that also involves a line of JavaScript. So this guide tries to be straight about all of it, including where our own fix script fits and where it doesn’t.

What an overlay is

The Overlay Fact Sheet, a document written and signed by accessibility practitioners, defines overlays as technologies that “apply third-party source code (typically JavaScript) to make improvements to the front-end code of the website” (Overlay Fact Sheet). It describes two kinds of feature:

1. Widgets: a toolbar of controls (contrast, text size, “screen reader mode”) added to the page.
2. Automated repair: scripts that scan the page in the visitor’s browser and attempt to fix problems as it loads.

Well-known vendors on the fact sheet’s list include accessiBe, UserWay and AudioEye. Pricing usually scales with traffic. accessiBe’s plans start at $59/month for up to 5,000 visits (accessiBe pricing), and UserWay’s Pro widget is $490/year for up to 100,000 page views (UserWay pricing).

The criticisms, and how solid they are

1. “The widget duplicates what users already have”

The fact sheet argues that people who need larger text, higher contrast or a screen reader already have those tools on their own device, because they need them on every site. A per-site widget is “at best, redundant functionality” (Overlay Fact Sheet). That seems reasonable to us. A widget doesn’t hurt sighted users who ignore it, but it isn’t what disabled users need.

2. “Automated repair can’t fix everything, and images are a weak spot”

The fact sheet lists limits on automated repair, starting with: “Automated application of text alternatives for images is not reliable”, followed by form labels, error handling, focus control and keyboard access. It concludes: “full compliance cannot be achieved with an overlay” (same source).

That matches what we see building an alt text tool. Even with good AI and page context, roughly speaking, a model can describe what’s in an image much more reliably than it can work out why it’s there. That’s why we require human approval.

3. “The marketing overclaims”

This is the criticism with a legal record behind it. In January 2025 the US Federal Trade Commission announced that accessiBe would pay $1 million to settle allegations that it misrepresented its AI tool’s ability to make websites WCAG-compliant, and that it formatted third-party articles and reviews to look independent (FTC, 3 Jan 2025). The Commission approved the final order in April 2025. It bars accessiBe from claiming its automated products “can make any website WCAG-compliant or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims” (FTC, 22 Apr 2025).

The complaint, as summarised by Seyfarth Shaw, quoted accessiBe’s claim that one line of code makes a site compliant with 30% of WCAG immediately and the remaining 70% within 48 hours, and alleged that the widget failed to make “menus, headings, tables, images, recordings, and more” compliant (Seyfarth, May 2025).

4. “Overlays don’t prevent lawsuits”

Lawsuit trackers keep finding widgets on sued sites. UsableNet’s 2026 midyear analysis found about 20% of companies sued had an accessibility widget or overlay installed (UsableNet, Jul 2026). The EcomBack tracker counted 983 lawsuits in 2025 against websites with a detected widget, 24.9% of the 3,948 it tracked (EcomBack). (The trackers count differently, so neither number is “the” figure.) What these numbers show is that installing a widget doesn’t stop people suing. They don’t show that widgets cause lawsuits.

5. “Overlays can create privacy risk”

The fact sheet notes that overlays which auto-detect assistive technology effectively detect disability, which is sensitive personal data, and that settings persisted across sites raise GDPR/CCPA concerns (Overlay Fact Sheet). Any script that runs on your visitors’ devices deserves a privacy review.

Why fixing the source wins

Fixing the source means changing your HTML, templates, CMS content and components so the accessible version is what every visitor, crawler and assistive technology receives. It’s better because:

• It works without JavaScript, for crawlers, slow connections, reader modes and browsers with scripts blocked.
• It survives redesigns and dynamic content. A runtime patch has to keep up with every change to your front end. A fixed template stays fixed.
• It’s what standards and courts look at. The Overlay Fact Sheet notes that frameworks like React or Vue may change the page “independently of the overlay, rendering it unable to fix those JavaScript-driven changes”.
• It builds team skills, so new content gets published correctly.

So when is a runtime patch reasonable?

Our honest position: a runtime patch can be a reasonable stopgap for a narrow, specific fix while the source is being corrected, as long as nobody claims it does more than it does.

Examples where it makes sense:

• A legacy CMS where image alt text can’t be edited without a developer, and the developer is booked for six weeks.
• A third-party template you’re migrating away from next quarter.
• A large catalogue import you’ll run next month, but customers are using the site today.

Examples where it doesn’t:

• As a substitute for fixing forms, keyboard access, focus or contrast. Those need source changes.
• As “compliance”. It isn’t.
• Indefinitely. Every month it’s in place, the source still isn’t fixed.

What the Altpass fix script is, and isn’t

We built a fix script because some site owners genuinely can’t edit their source quickly. Here’s exactly what it does, so you can judge for yourself:

It is: - A small script (<script src=".../fix.js?site=ID">) that, on page load, applies alt text you have reviewed and approved in Altpass to the specific images you approved it for. - Real alt attributes on real <img> elements, readable by any screen reader that sees the updated page. - Removable at any time, with the same approved alt text available as a CSV export so you or your developer can put it into the source, which is what we recommend.

It isn’t: - A widget. There’s no toolbar and no “accessibility mode”. - An AI that rewrites your page unsupervised. Nothing is applied without your approval. - A detector of assistive technology. It doesn’t try to work out who’s using a screen reader. - A fix for anything other than image alt text. - A compliance product. Using it doesn’t make a site WCAG-conformant, ADA-compliant or EAA-compliant, and we won’t say otherwise.

Our recommended path: check → draft → approve → export CSV → fix in the source, using the fix script only to cover the gap if you need one.

A practical decision guide

Start with the facts about your site

Run the free Altpass checker to see which images on a page have missing or weak alt text. It’s free and needs no signup. Whatever you decide about stopgaps, the fix starts with knowing what’s broken.

Updated 2026-10-07