If you run a website, you have probably been pitched an "accessibility overlay" — a single line of JavaScript that promises to make your site compliant with the WCAG standards and safe from lawsuits, automatically, overnight. It sounds too good to be true, and the short version is that it is. This is a question we get constantly, and because we sell an accessibility widget ourselves, you have every reason to be suspicious of our answer. So let's be direct, lead with the evidence against overlays, and only then talk about the narrow, honest place where a widget actually earns its keep.
The short answer
No. An accessibility overlay cannot, by itself, make an inaccessible website accessible or compliant. That is not our opinion — it is the strong consensus of the people who write the accessibility standards, build the screen readers, and get hired to test real sites. Before we say a single word in defense of widgets, here is the case against relying on them:
- Regulators have acted. In April 2025 the U.S. Federal Trade Commission finalized a $1 million settlement with accessiBe, one of the largest overlay vendors, over deceptive claims that its AI product could make any website WCAG-compliant and protect businesses from litigation. The complaint was filed in January 2025.
- The experts objected, in writing and at scale. The Overlay Fact Sheet, a public document maintained by accessibility consultant Karl Groves, has been signed by more than 1,000 accessibility professionals — including people who contribute to the WCAG, ARIA, and HTML specifications, contributors to the JAWS and NVDA screen readers, and accessibility staff at major technology companies.
- Practitioners rate them poorly. WebAIM's Survey of Web Accessibility Practitioners #3 (2021) found that a majority of practitioners consider overlays "not effective" at making sites accessible.
When the standards authors, the screen-reader community, working practitioners, and a federal regulator all point in the same direction, that is about as close to a settled answer as this field gets.
Why the backlash is real
The pushback against overlays is not a marketing skirmish between competitors. It comes from the people whose daily work is accessibility, and it rests on evidence.
The Overlay Fact Sheet
The Overlay Fact Sheet exists because the same overblown claims kept reaching disabled users and the professionals who serve them, and those claims did not survive contact with reality. Its core argument is straightforward: an automated script bolted onto the front end cannot reliably fix the issues that actually block people — meaningful alt text, correct form semantics and error handling, keyboard operability, dynamic content in single-page apps, and PDFs. Worse, the Fact Sheet documents cases where overlays introduce new barriers and raise privacy concerns, because some overlays attempt to detect whether a visitor is using assistive technology.
The signatory list matters here. When contributors to the very specifications an overlay claims to satisfy sign a document saying the technology cannot do what it advertises, that is not a difference of taste. It is the authors of the rulebook telling you the shortcut does not lead where the sign says.
The accessiBe case
Regulators reached the same conclusion. The FTC's action against accessiBe was specifically about deceptive advertising: claiming an AI tool could make any website compliant and shield a business from legal exposure. Separately, in 2021 the National Federation of the Blind — the largest organization of blind people in the United States — publicly criticized accessiBe and barred the company from its national convention, citing the harm caused by overselling automated fixes to the very users those fixes were supposed to help.
The lawsuits kept coming
The most quietly damning fact is this: businesses that installed overlays got sued anyway. Overlay vendors have marketed their products as legal protection, but courts and settlements have not accepted "we installed an overlay" as evidence of good-faith ADA compliance. There is a well-documented pattern of overlay-equipped sites receiving accessibility lawsuits — in some cases the overlay's own accessibility problems became part of the complaint. If the product's central promise is protection from litigation, and litigation arrives regardless, the promise has failed on its own terms.
What the criticism gets right
It helps to understand why an overlay structurally cannot deliver compliance. It is not that vendors are lazy; it is that the hard parts of accessibility require human judgment and access to the underlying code, and an overlay has neither.
- Alt text is a judgment call. A script can detect that an image is missing a text alternative. It cannot know whether a photo is decorative, whether it is a product shot that needs the SKU and color described, or whether it is a chart whose data must be conveyed in prose. Auto-generated alt text is frequently wrong in ways that actively mislead a blind user.
- Forms need real semantics. Correctly associating labels with inputs, exposing required fields, and announcing validation errors depends on the form's actual markup and state. Guessing from the outside produces labels that are close but wrong — which can be more confusing than no label at all.
- Single-page apps change under the overlay's feet. Modern sites rebuild the DOM constantly. An overlay that patches the page on load cannot keep up with content that appears, updates, and disappears as the user interacts, and it often has no reliable way to announce those changes.
- PDFs are out of reach. A huge share of real-world content lives in documents. An overlay operating on the HTML page cannot remediate an inaccessible PDF.
- Keyboard operability is architectural. Whether a custom dropdown, modal, or carousel can be operated and escaped with a keyboard depends on focus management built into the component. An overlay cannot reliably retrofit that from the outside.
Then there is the privacy dimension. To decide which "profile" of adjustments to apply, some overlays try to infer that a visitor is using a screen reader or other assistive technology. Detecting disability status — even to help — is exactly the kind of inference many disabled users do not want a website making, and it can happen without meaningful consent.
And the failure mode is not neutral. When an overlay guesses wrong — mislabels a control, hijacks focus, fights the user's own screen reader — it does not leave the site as it was. It makes the experience worse for the people it claims to serve. "First, do no harm" is a low bar, and overlays sold as compliance have repeatedly failed to clear it.
Where a widget genuinely helps
Here is the part the loudest marketing gets wrong and the loudest criticism sometimes overshoots. A front-end widget cannot fix your code — but it can offer real user-facing conveniences that some people genuinely value. The honest framing is the entire point: these are accommodations, not compliance.
A well-built widget can let a visitor:
- increase text size and spacing without zooming the whole layout;
- switch to a higher-contrast color scheme;
- apply a dyslexia-friendly font;
- enlarge the pointer or add a reading guide and stronger focus indicators;
- pause animations and stop auto-playing motion.
Notice who these help. The population that benefits from on-page toggles is largely distinct from dedicated screen-reader users. A person with low vision who does not use a screen reader, someone with a motor condition who needs a bigger target and clearer focus, someone with a vestibular disorder who needs motion to stop, someone under heavy cognitive load who reads more easily with more spacing — these are real users, and a toggle can make a real page more comfortable for them right now.
That is a legitimate, modest benefit. What it is not: a fix for the underlying page, a substitute for accessible code, or anything that touches the deeper WCAG failures described above. A contrast toggle does not add alt text. A font switch does not make your checkout form operable by keyboard. Calling these features "compliance" is precisely the lie that got an industry sued and fined. Calling them "accommodations that help some visitors" is simply true.
The only credible path: pair the widget with a real audit
If a widget cannot make you compliant, what does? The unglamorous answer is a real accessibility audit followed by tracked fixes in your actual code. A credible audit is layered:
- Automated testing (using engines like axe-core) catches the machine-detectable issues fast and at scale — missing alternatives, contrast ratios below threshold, missing form labels, invalid ARIA. This typically surfaces a large share of failures but only a portion of the WCAG success criteria, because most criteria require human judgment.
- Manual expert review covers what automation cannot: is the alt text meaningful, is the reading and focus order logical, do error messages actually help, is the content understandable.
- Assistive-technology testing — driving the site with real screen readers and by keyboard alone — confirms the experience holds together for the people it is meant to serve.
The distinction is not subtle. "Widget = compliance" is a claim that regulators have penalized. "Widget + audit + tracked remediation" is a fundamentally different proposition: you use a scanner and expert review to find what is broken, you fix it in the source, you re-test, and you offer a widget on top purely as a comfort layer for the users it happens to help. One is a shortcut that does not exist; the other is just the work.
This is how Inclusify is built, and we would rather tell you the structure plainly than dress it up. We run automated WCAG scans against your pages, produce reports that separate confirmed issues from items needing human review, and track remediation over time so you can see progress on the code itself. We also offer a widget for the accommodation use cases above. We keep those two things clearly labeled and separate, because merging them is the exact mistake this article is about. The scanner tells you where you stand; the widget is a convenience, not a certificate.
Can you trust a company that sells a widget to write this?
Fair question, and it deserves a plain answer rather than a defensive one. Yes, we sell a widget, and yes, that is a bias you should weigh. So read this piece skeptically — that is the correct instinct, and it is the same instinct that should make you skeptical of any vendor promising instant compliance.
Here is our actual position, stated so you can hold us to it: a widget is an accommodation, not compliance. It will not fix your code, replace an audit, or protect you from a lawsuit, and we will not tell you otherwise to close a sale. If a widget were a magic compliance button, we would happily sell you one and skip the harder conversation about audits and remediation. It is not, so we won't. The most useful thing we can offer is an honest picture of where your site stands — and if that picture says your real problems are in the code, a widget is not the answer, and we will say so.
Frequently asked questions
Do accessibility overlays make my site ADA compliant?
No. An overlay cannot make an inaccessible site compliant. The ADA is enforced against the actual experience your site provides, and overlays do not reliably fix the underlying issues — alt text, form semantics, keyboard operability, dynamic content, PDFs — that determine whether a site is usable. Courts and settlements have not treated installing an overlay as evidence of compliance. This is general information, not legal advice; consult a qualified attorney for your situation.
Can an overlay cause a lawsuit?
An overlay does not automatically cause a lawsuit, but it does not prevent one, and it can make you an easier target. Businesses running overlays have been sued anyway, and in some cases the overlay's own defects — hijacked focus, incorrect labels, interference with screen readers — became part of the complaint. If your underlying site is inaccessible, an overlay marketed as protection can create a false sense of safety while leaving the real barriers in place.
Are accessibility widgets ever useful?
Yes, in a narrow and honest way. A widget can provide genuine conveniences — text sizing, contrast, dyslexia-friendly fonts, focus and pointer aids, pause-animations — that help some visitors, particularly people with low vision, motor differences, or cognitive load who are not necessarily screen-reader users. These are accommodations, not compliance. Treated as a comfort layer on top of accessible code, a widget is helpful. Treated as a substitute for accessible code, it is the exact mistake this article warns against.
If you want to know where your site actually stands — not whether a script can hide the problems, but which WCAG issues are really there — run a free WCAG scan. Treat it as a diagnostic: it tells you what to fix in your code, which is the only thing that moves you toward real accessibility.
