Why accessibility overlays fail
One category of product dominates the accessibility widget market: the overlay. For a monthly fee, a vendor promises to make your site accessible by injecting a JavaScript layer that reads your page and attempts to repair whatever it finds. No developer required, no code changes, compliance handled in a single installation. The pitch is compelling.
The pitch does not hold.
What overlays actually do
An overlay loads a script that modifies the accessibility tree after the page renders. It tries to remap missing alt attributes, infer labels for unlabeled form fields, and adjust keyboard behavior. The interface typically adds a floating icon, a small person, wheelchair graphic, or gear, that visitors can open to set their preferences.
The problems start at the technical level. Screen readers, the primary assistive technology for blind and low-vision users, build their model of the page from the DOM and the accessibility tree at load time. An overlay modifies that tree after the fact, sometimes in conflict with what the screen reader has already parsed. The result is a page that behaves erratically: elements that respond to the overlay's remapping but break the screen reader's expected navigation patterns. This is why many screen reader users turn overlays off entirely. The interference is often worse than the underlying issues the overlay was supposed to fix.
Beyond the technical breakage, overlays are limited to what automated analysis can detect. Custom interactive components, non-standard ARIA implementations, and visual cues that cannot be inferred from markup are all invisible to the script. An overlay that cannot detect a problem cannot fix it. The issues it does fix, it fixes inconsistently and only at runtime, meaning the underlying code remains broken and any future page variation or A/B test that bypasses the script starts from scratch.
The FTC's enforcement action against accessiBe
In 2024, the Federal Trade Commission took enforcement action against accessWidget, Inc., the company behind accessiBe, resulting in a $1 million settlement. The central issue was marketing claims that the software would bring websites into compliance with the Americans with Disabilities Act.
The enforcement action did not turn on whether overlays are useful tools in a limited sense. It turned on the gap between what the product was sold as and what it actually delivered. An automated JavaScript layer cannot substitute for manual testing, screen reader verification, and the code-level remediation that real accessibility requires. Selling it as a compliance solution, and pricing it as an alternative to genuine remediation work, is the claim that did not survive scrutiny.
Courts have not treated overlays as a defense
The legal rationale for purchasing an overlay is straightforward: demonstrate good-faith effort, reduce lawsuit exposure. The court record does not support this theory. Plaintiffs have successfully brought ADA web accessibility lawsuits against defendants who had overlay software installed. Judges evaluating accessibility under the ADA look at whether the site actually works for users who rely on screen readers and other assistive technology, not whether a JavaScript widget is present on the page.
The European Accessibility Act, which came into force in June 2025, takes the same approach. The EAA requires products and services in scope to meet EN 301 549, the European standard aligned with WCAG 2.1. A runtime JavaScript overlay does not produce EN 301 549 conformance, and EU enforcement does not evaluate conformance by checking whether an overlay is installed.
What real remediation looks like
Fixing accessibility means fixing the underlying code. When a product image is missing alt text, the fix is adding the attribute. When a form field has no label, the fix is associating a label element with a for attribute. When ARIA is misused, the fix is correcting the markup. These changes are often straightforward, measured in lines rather than files, and stay fixed across every page load, every device, and every future version of the page.
The starting point is knowing what is actually wrong. A scan names each broken element, links to where it appears on the page, and describes what the fix is. From there, a developer can make the change, verify it works in a screen reader, and confirm it does not regress in the next release. That is the process overlays shortcut but cannot replace.
The bottom line
Overlays are less expensive than genuine remediation work, and years of marketing have made them the default mental model for "doing something about accessibility." But the technology has well-documented limits, a federal regulator has acted on the compliance claims, and courts have not found overlay installation to be a meaningful defense in ADA web cases.
The practical question for most sites is not "overlay or full manual audit." Manual audits by certified accessibility specialists run $5,000 to $20,000 and upward for a full site. The middle path is automated scanning that finds the real issues in your code, gives you concrete fixes for each one, and tells you when new problems appear after releases. That is a different thing from a widget that patches the surface of your page while the underlying code stays broken.
If you want to see which real issues are present on your own site, the free scan covers your homepage and returns a report you can hand directly to a developer.