Why accessibility overlays fail an audit

The demo is good. That's the part people don't say out loud. A salesperson pastes one line of JavaScript into your site, an accessibility icon appears in the corner, and the page starts doing things — text grows, colors invert, a voice reads the page aloud. Nothing was rebuilt. It took ninety seconds.

Then the audit comes back and almost nothing has moved. Not because auditors are hostile to the product, but for five specific mechanical reasons. Worth knowing them by name, because "overlays don't work" is an assertion and these are reasons.

1. Conformance is measured on the page you actually deliver

WCAG's conformance requirements are explicit that a claim applies to full pages as delivered. 1.4.3 Contrast (Minimum) is evaluated against the page's default presentation — not a high-contrast mode a visitor can switch on from a menu.

So the profiles don't remediate anything; they add an alternative the user has to discover, open, and configure. And the people most affected already brought their own tools. A blind resident arriving at your site has a screen reader running before the page loads, tuned over years. Being asked to find your widget and switch on "screen reader mode" is not an accommodation.

2. A guessed alt attribute is a wrong answer, not a missing one

Overlays generate alt text with computer vision. 1.1.1 Non-text Content, Level A, does not ask for a description of the image — it asks for an alternative that serves the equivalent purpose. A machine caption of "a group of people outside a brick building," for a photo whose purpose on the page is "council votes 4–1 to approve the sales tax," is an accurate description and a failing alternative.

3. Entire criteria are out of a DOM script's reach

An overlay is JavaScript running inside your web page, and it can only touch things inside your web page.

It cannot caption your recorded council meetings — 1.2.2 Captions (Prerecorded), Level A. It cannot tag your agenda PDFs, which are separate files it never sees. It cannot fix contrast in text baked into an image. And guessing headings from font size is a heuristic that can invent a structure that isn't there, which is its own 1.3.1 Info and Relationships finding.

4. The widget is content on your page too

WCAG's non-interference requirement means non-conforming content can't get in the way of the rest. The overlay's own button and panel are content, and owe the same criteria as everything else: 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.7 Focus Visible, 4.1.2 Name, Role, Value.

This is where overlays actively add findings. Panels that trap focus. aria-hidden applied to page regions that then vanish from a screen reader while staying reachable by Tab. Renamed controls whose accessible name no longer matches the visible label, breaking 2.5.3 Label in Name, Level A — and with it voice-control users, who say the words on the button and get nothing. Containers given role="application", which tells assistive technology to stop intercepting keystrokes and pass them to the page, disabling the reading commands the user depends on.

5. It's a race, and the script can lose

The fixes are applied after the page renders. Anything drawn later — the calendar, the search results, the agenda list pulled from your meeting-management vendor — may never get patched. If the script is slow, blocked by an extension, or fails to load, every "fix" disappears at once.

Here's the mechanism that explains all of the above

An overlay is optimized against the half of an audit that decides nothing.

WCAG 2.1 has 50 success criteria at Level A and AA, and only a minority can be settled by a machine at all. The rest need a person to judge whether an alternative serves the same purpose, whether a reading order makes sense, whether an error message tells you how to fix the error. Automated scanning is the cheap mechanical part — and it is exactly the part an overlay is built to satisfy, because mutating the DOM before the scanner reads it is easy.

So the error count really does fall, sometimes to zero, and the screenshot goes in the council packet. The manual findings list doesn't move, because nothing about the underlying page changed. The number that improved is the number nobody is judged on.

If you already have one

Keeping or removing the widget makes little difference to an audit result either way — but do turn off anything it does to ARIA attributes and roles on your markup. That is the part with real potential to make things worse for people who already have their own assistive technology.

And put this in front of whoever signed the contract: in January 2025 the FTC brought an action against overlay vendor accessiBe over claims that its product could make any website WCAG compliant. The final order, approved that April, requires a $1 million payment and bars the company from repeating those claims without evidence to support them. That is a federal regulator stating on the record that "install this and you're compliant" was not substantiated.

Paying for an overlay and want to know what your site actually scores without it? Ask me and I'll test both.