Overlay widgets vs source scans
Overlay widgets sit on the visitor’s session. A source scan sits on what you shipped.
Those are different products. Treating them as interchangeable is how teams buy a widget, keep failing HTML, and still get sued.
An accessibility overlay (accessWidget, UserWay, and similar) is JavaScript added to a live site that offers a toolbar and, vendors have claimed, automatic remediations. A source scan loads the page in a controlled browser, runs an engine such as axe-core against the DOM, and records cookies and headers. It does not sit on the visitor’s session.
When we tested this, the overlay did not change the unlabeled button in the HTML we crawled. axe-core still failed the name rule. The toolbar was a second UI. The source was the same.
Why overlays became a backlash story
Vendors sold speed: paste a snippet, “make any website WCAG-compliant.” Disabled users and researchers documented cases where the overlay did not fix source issues and sometimes made assistive technology worse.
In January 2025 the U.S. FTC announced a proposed order requiring accessiBe to pay $1 million over allegedly deceptive WCAG-compliance claims. The Commission approved the final order on 22 April 2025. Read that sentence twice. The order is about marketing claims, not a ban on overlay scripts.
UsableNet counted 1,023 companies sued in 2024 while an accessibility widget was live (2024 Year-End ADA Web Lawsuit Report). A toolbar on the page is not evidence that source HTML, keyboard access, or a screen reader actually work.
The WebAIM Million still found detectable WCAG 2 failures on 95.9% of top home pages in 2026. Overlays have had years to “fix the web.” The automated failure rate went up, not down. Figures and links sit on the statistics hub.
What a source scan is for
You want a list of failures in the HTML you ship, plus cookie behavior, plus a PDF you can send. You do not want a third-party UI on the customer’s site.
That is the accessiBe alternative and UserWay alternative framing: different job, not a clone of the widget.
Complience.app will not certify the live site. It will tell you what axe saw after a Playwright load. In practice, that list is what a developer can search in the theme, the CMS, or the repo. A toolbar cannot be grepped. If the CMS is WordPress, start at the WordPress accessibility checker.
What actually works is fixing labels, contrast, and names in source, then recrawling. The overlay never enters that loop.
Practical advice
Remove the overlay if it is there as a legal talisman. Fix labels, contrast, and names in source. Check the public URL so you have a baseline that does not depend on a toolbar.
The W3C’s Understanding Conformance page does not list “inject a third-party widget” as a conformance method. Conformance is about the content. Source is the content.
If a client asks whether the FTC “banned overlays,” the accurate answer is no. The accurate follow-up is that 1,023 sued-with-widget sites already answered the “is this a shield?” question.
Questions
- Are overlay widgets illegal after the FTC accessiBe order?
- The FTC order is about deceptive compliance claims and endorsements, not a ban on overlay scripts. Sites were still sued in 2024 with widgets installed. Do not treat a widget as a legal shield.
- Is Complience.app an accessiBe alternative?
- Only in the sense that buyers comparison-shop. Complience.app scans source and produces a report. It does not inject a widget or claim to make the live site compliant.
Want evidence on a live URL? Run a free accessibility check.