An overlay vendor's scan landed in a client's inbox in August with a sales pitch attached. By the time I got involved, three different things were being called an accessibility check. Only one of them was.

An accessibility overlay is a snippet of JavaScript sold as compliance in a box. It's not compliance. Conformance is a property of the whole page, not of a layer that loads last and patches whatever it finds.

Here is the part I did not expect. That site was already running a runtime accessibility layer, and that one was earning its keep. So this is not a post about patching at runtime being bad. It's about what happens when somebody sells you the patch as a finish line.

Why This Keeps Landing in Inboxes Right Now

Three things converged. First, enforcement. According to the Federal Trade Commission, accessiBe agreed on January 3, 2025 to pay $1 million over allegations it misrepresented its accessWidget product as able to make any website WCAG compliant. The complaint also said the company dressed up third-party articles to look like independent reviews. The final order came through in April 2025.

Second, the standard moved and most people didn't notice. WCAG 2.2 became a W3C Recommendation on October 5, 2023. It keeps everything from 2.0 and 2.1, drops 4.1.1 Parsing, and adds nine criteria, six of them at Level A or AA. A site assessed as conformant in 2022 was assessed against a different standard. Nobody did anything wrong. The certificate in the drawer is just stale.

Third, the web is getting worse. The 2026 WebAIM Million found detectable WCAG failures on 95.9 percent of the top million home pages, up from 94.8 percent, with 56.1 errors on the average page. That is the first regression after six straight years of small gains. Real pressure, a moving standard, and a line of vendors ready to sell you out of it. Small businesses have been through this exact shape before with website privacy compliance.

An Accessibility Overlay Scan Is a Sales Document First

The scan that started all this came from a company that wanted to sell the client a subscription, and it read like it. That's not an accusation. It's what the document is for.

So the severity ratings run hot. Checks that do not apply to the page get counted anyway and pad the total. Things a human has to judge come back as defects instead of questions. The findings underneath are usually worth triaging, because the engine does catch real contrast failures and real missing labels. It's the framing you discount, not the data.

The product has a harder limit than that. An accessibility overlay runs after the page loads and patches what rendered. It can't know whether an image with empty alt text is decorative or load-bearing. It can't turn a link that says "click here" into something useful, because it doesn't know where the link goes. The FTC order now bars accessiBe from claiming its automated products can make any website WCAG compliant unless it has evidence. Read that sentence again. That's the whole argument.

A Green Check Sat On Top of a Level A Failure

The client asked for WAVE by name, so I ran WAVE. Good tool, free, and a reasonable thing to ask for. I report its numbers verbatim in every audit I write.

Then it gave one page a green Feature marker for Language, and the language that page declared was flat wrong. The page did declare a language. That is all an automated engine can check. It has no way to know the declared language doesn't match what a human reads on screen. A screen reader hits that page and pronounces the whole thing wrong.

That's not a knock on WAVE. WebAIM says it themselves in the WebAIM Million methodology note: absence of detected errors does not indicate that a page is accessible or conformant. The tool is honest about its limits. Trouble starts when somebody treats a number from it as a verdict.

Two more misreadings come up constantly. Zero Errors isn't a pass, because WAVE counts contrast separately, so a page can show zero errors and dozens of contrast errors in the same breath. And Alerts aren't failures. They flag what a human has to judge, and legitimate content lands there all day.

Three of My Own Findings Were Wrong

My tooling gets no pass here either, and the useful part of the story is where it was wrong.

One element came back flagged as entirely covered by a fixed overlay. That would've been a 2.4.11 failure. It was a carousel slide parked at an x coordinate of negative 5316, never visible to anybody. The test was measuring something off-screen.

A mobile menu toggle looked unlabeled and unreachable by keyboard. It was a span inside a parent div carrying a button role, a tabindex, and a perfectly good aria-label. The element was fine. The test was looking at the wrong node.

Thirty-nine images with empty alt text looked like a clear 1.1.1 failure. They were logos. Whether empty alt is right for a logo depends on whether the copy beside it already names the thing, and often empty alt is exactly right. That one is an editorial call. No script settles it.

Every automated signal is a hypothesis until somebody confirms it on the live page. That's the part that gets you. A report that overstates is worse than no report, because the client acts on it, and the credibility's gone the first time anybody checks a finding and discovers it was never real. I use AI tooling to audit sites constantly. I don't let it write a finding.

Not Every Runtime Layer Is the Thing the FTC Fined

Here's where I have to complicate my own argument, because that site was running Divi Assistant, and its Accessibility Helper works the same way an overlay does. It adds a skip-to-content link, an outline on focused elements, aria attributes on modules, aria-hidden on decorative icons, and labels on form inputs that never had them. All of it applied after the fact. Same mechanism.

I kept it, and I said so by name in the report. A client paying for accessibility deserves to know what is already working. That layer was doing real, specific work on known Divi gaps, and the site was in noticeably better shape for it.

Now read what that does not say. It was running, and I still confirmed eleven issues. Both true. Neither one cancels the other. A runtime layer fixes a list of things somebody wrote down in advance. It doesn't fix your page language, your brand color contrast, your alt text, or your link wording, because nobody can write those down in advance for you.

So the difference between that and an accessibility overlay is not the JavaScript. It's the promise attached to it. One is a tool that closes a known set of gaps and leaves the rest of the job visible. The other is sold as the job being over. Once the widget is installed and the box is ticked, the organization stops asking, and the barriers sit exactly where they were.

Where I Could Be Wrong About This

My evidence is one audit on one site plus the public record. Eleven findings is a sample of eleven, and I wouldn't hand you that number as a statistic. Run the count on your own site.

I could also be wrong about where this goes. Overlay technology in 2026 isn't what it was in 2019. What would change my mind is independent testing, run by people with disabilities rather than by the vendor, showing a widget measurably removes barriers on sites it was never tuned for. I haven't seen it yet.

What to Do Instead of Buying the Widget

Start by finding out what you already have, because plenty of sites are running a layer the owner forgot about. Check four things in the served HTML. Whether the viewport meta tag blocks pinch zoom. Whether a skip link exists and points at an element that's really there. Whether a main landmark is present. Whether prefers-reduced-motion shows up anywhere in the CSS. Twenty minutes, and it tells you more than any scan.

Then run a free scanner. Free browser-based tools are genuinely useful here. Treat everything that comes back as a candidate and confirm each one on the live page before you write it down.

Then go after the six that do most of the damage: low contrast text, missing image alt text, missing form labels, empty links, empty buttons, and a missing document language. WebAIM found those six account for 96 percent of all detected errors, and they have been the same six for seven years running. Low contrast alone shows up on 83.9 percent of home pages. None of it needs a rebuild.

Then do the step everybody skips. Open NVDA or VoiceOver and try to use your own contact form. You'll learn more in that half hour than from any report, mine included.

One Question Worth Asking Your Vendor

Whoever is selling you an accessibility overlay, or an audit, or anything in between, ask them one thing. What did you confirm by hand, and what did a script tell you? Any honest answer separates an audit from something shaped like one.

I'm not a lawyer, and nothing here tells you where you stand legally. What I can tell you is what an audit is. Somebody looked. Somebody checked what the tools claimed. Somebody put their name on the result. A widget does none of that. Neither does a score.

Sources

• Federal Trade Commission, FTC Order Requires Online Marketer to Pay $1 Million for Deceptive Claims that its AI Product Could Make Websites Compliant with Accessibility Guidelines, January 3, 2025
• Federal Trade Commission, FTC Approves Final Order Requiring accessiBe to Pay $1 Million, April 2025
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, October 5, 2023
• WebAIM, The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages, March 2026
• Pee-Aye Creative, How To Improve Divi Accessibility With The Divi Assistant Plugin