The short version of accessibility widget vs overlay: a preference widget is a small on-page menu that lets visitors adjust how a site looks — bigger text, higher contrast, reduced motion — on a site that is already built accessibly underneath. An overlay is a third-party JavaScript script sold on the promise that it will automatically make a broken website compliant. The first is a legitimate convenience that makes no legal claim. The second makes a claim it cannot keep, and it is exactly the kind of product that has drawn regulator fines and thousands of lawsuits.
That distinction matters because the two are constantly marketed as the same thing. The button in the corner of a page is not the problem. The sales pitch attached to some of those buttons — 'install one line of code and you're covered' — is the problem.
What is an accessibility widget?
A true access or preference widget hands control to the user. It typically offers settings like larger font size, a high-contrast color scheme, underlined links, a readable font, or paused animations. These are display preferences layered on top of a site whose underlying code is already sound — semantic HTML, real alt text, labeled forms, keyboard operability.
Used this way, a widget is harmless and often genuinely helpful. It makes no representation that it fixes anything. ADA Fail's own site runs one, precisely because the code beneath it already meets WCAG 2.2 AA — the widget is a nicety, not a patch. The tell is simple: a preference widget adjusts a site that already works, and it never claims to make the site 'compliant.'
What is a compliance overlay?
An overlay is a script you paste into your site that promises to detect and correct accessibility problems automatically, usually in real time. The marketing language is the giveaway: 'ADA compliant in 48 hours,' 'AI fixes your accessibility,' 'one line of code.' Some overlays include a preference menu too, which is how they blur the line — but their selling point is the compliance guarantee, not the settings.
Here is the core issue. Automated tooling of any kind can detect only roughly a third of WCAG success criteria. The rest — meaningful alt text, logical reading order, whether a form error actually makes sense to a screen-reader user — require human judgment. An overlay running in the browser cannot supply that judgment, and it frequently interferes with the assistive technology a disabled visitor is already using. We go deeper on the mechanics in why overlay widgets fail.
Why the compliance claim is the legal trap
The claim is what creates liability, not the code. In January 2025 the FTC announced a settlement with overlay vendor accessiBe: a $1 million penalty over allegations that the company deceptively claimed its widget could make any website WCAG-compliant — '30% immediately and the remaining 70% via AI within 48 hours' — and dressed up paid reviews as independent. The final order bars those unsubstantiated compliance claims outright.
The National Federation of the Blind, the largest organization of blind Americans, formally opposes overlay products and describes them as 'not only ineffective but harmful.' And when researchers analyzed the top million homepages, sites running an overlay averaged roughly as many detectable errors as sites without one. The script did not move the needle.
Does an overlay actually protect you from a lawsuit?
No — and the data points the other way. Digital-accessibility lawsuits are not slowing down: more than 5,000 website and app suits were filed in 2025, up roughly 20% over the prior year, part of 8,667 ADA Title III filings overall. UsableNet's year-end reporting repeatedly finds that hundreds of the companies sued each year already had an accessibility widget or overlay installed at the time they were sued.
Think about what that means. A serial plaintiff's attorney can see the overlay in your page source. Far from a shield, it can read as an admission that you knew there was a problem and reached for the cheapest possible fix. In California, where the Unruh Act sets minimum statutory damages of $4,000 per violation plus attorney's fees, that math gets expensive fast. Most web-accessibility cases settle for between $10,000 and $75,000 plus a remediation commitment — meaning you often pay for the overlay, the settlement, and the real fix.
How do you tell a widget from an overlay?
Ask what the product claims to do. Run through this quick check:
- Read the claim. Does it promise 'compliance,' 'ADA compliant,' or automatic legal protection? That's the overlay red flag. A preference tool only offers to change how the page displays.
- Look under the hood. Was the site built accessibly first, with the widget added as a convenience? Or is the script the entire accessibility strategy? A button bolted onto broken code fixes nothing.
- Check who's in control. A preference widget lets the user choose settings. An overlay claims to make automatic corrections on the user's behalf — often the corrections that break assistive tech.
- Follow the pricing logic. Genuine remediation is code work priced like code work. A flat monthly subscription that promises to keep you 'compliant' forever is selling a claim, not a fix.
If you're not sure which one is sitting on your site, a free accessibility audit will tell you exactly what your code does and doesn't do — no subscription, no script to install.
What actually reduces your risk
Real risk reduction is unglamorous: audit the site against WCAG 2.2 AA, fix the underlying code, and keep testing as the site changes. Automated scanning is a useful first pass — it catches the low-contrast text, missing alt attributes, and unlabeled form fields that make up the most common failures across the web. But passing an automated scan is not the same as conforming to WCAG; only expert human testing, including screen-reader and keyboard testing, can speak to full conformance. A basic ADA website compliance checklist will walk you through the essentials.
A preference widget can absolutely be part of a good site. Add it on top of accessible code, and it's a thoughtful touch. Bolt it onto broken code and call it done, and you've bought a false sense of security that a plaintiff can screenshot.
Frequently asked questions
Is it safe to keep the accessibility widget already on my site?
It depends on which kind you have. If it's a pure preference tool — text size, contrast, motion controls — and your underlying code is accessible, there's no problem keeping it. If it's an overlay that makes automatic 'compliance' corrections, it may be interfering with visitors' assistive technology and signaling the wrong thing to a plaintiff's attorney. The first step is finding out which one you have; if it's an overlay, see how to remove an accessibility overlay cleanly.
If overlays don't work, why do so many businesses use them?
Because the pitch is irresistible: one line of code, a flat monthly fee, and a promise of legal protection with no development work. For a busy business owner that sounds like the whole problem solved. The reality is that the underlying code still fails for real users, and the lawsuits keep coming — as the record number of 2025 filings shows. The convenience is real; the protection is not.
What should I do instead of installing an overlay?
Start with an honest assessment of your actual code, then remediate the real defects and re-test. Automated scans quickly surface the common issues — contrast, alt text, form labels — and human testing covers the two-thirds of WCAG that machines can't judge. If you've already received a demand letter, get the code assessed before you respond or reach for a quick-fix script.
Not sure whether the tool on your site is a harmless preference widget or a liability-generating overlay? Get a free accessibility audit from ADA Fail. We'll show you what your code actually does, flag any overlay dragging you toward risk, and give you a clear, plain-English path to fixing the site for real users — not just hiding the problem behind a button.