Insights · 23 October 2026
Why an accessibility widget will not make you compliant
Overlay widgets promise accessibility in one line of JavaScript. They are cheap, quick to install and easy to sell. In 2025 the US Federal Trade Commission ordered one vendor to pay $1 million over exactly that promise. Here is what overlays do, what they cannot do, and what to do instead.
What an overlay does
An overlay is a script loaded on top of a website. It adds a toolbar that lets visitors change text size, contrast or spacing, and it tries to patch some defects at runtime, for example by guessing alt text for images or adding labels to unlabelled fields after the page loads.
The code underneath does not change. A button with no accessible name still has none in the source. A custom dropdown that traps keyboard focus still traps it. Many screen-reader users already have the adjustments an overlay offers built into their own software, configured the way they like.
What the FTC found
In January 2025 the FTC announced a proposed order against accessiBe, and finalised it in April 2025. The order required a $1 million payment and barred the company from claiming that its product can make any website conform to WCAG, or keep it conformant over time, unless it has the evidence to back that claim. It also dealt with paid endorsements presented as independent reviews.
The order is not a ban on overlays, and it applies to one company. But it sets out the regulator's view plainly: a script on top of a site is not evidence that the site meets the standard.
What courts and regulators look at
Neither US courts nor EU market-surveillance authorities assess the presence of a widget. They assess whether a disabled person can use the site. In the US, courts usually take WCAG 2.1 AA as the benchmark. In the EU, the technical standard is EN 301 549. Both describe the behaviour of the page itself: names, roles, focus, contrast, structure.
Plaintiffs' firms in the US test sites with screen readers before filing. AudioEye's 2026 litigation report, cited in its full-year results, found that 38.5% of sued businesses already had a widget-based solution in place when the claim arrived. AudioEye sells its own automated product, so read that figure with its source in mind; it is still consistent with what the FTC found.
What to do instead
- Fix the code. Defects belong in the source: semantic HTML, names and roles for custom controls, focus management, contrast in the design tokens.
- Test with assistive technology. Automated scanners find roughly a third of WCAG failures. The rest need a screen reader, a keyboard and a person.
- Keep the evidence. A dated record of how each criterion was tested is what a procurement reviewer, a regulator or a court will ask for.
- Re-check after every release. Nearly half of US federal web accessibility suits in 2025 named a company that had been sued before.
If you already run an overlay, removing it is not the first step. Fix the defects underneath, verify the fixes, and then decide whether the toolbar still adds anything your users want.
Sources: Law Office of Lainey Feingold, FTC order summary; ADA Compliance Pros, overlay pricing and claims; Seyfarth Shaw, 2025 lawsuit filings; AudioEye, full-year 2025 results; WebAIM Million 2026.
See what verified accessibility looks like.
A full sample report for a demo store: every WCAG 2.2 AA criterion, the method behind each result, a fix shown as a pull request, and a sample conformance report.