OVERLAYS EXPLAINED
Why an accessibility overlay is not compliance
Overlays promise instant accessibility from a single line of code. Regulators, courts, and the accessibility community have reached the opposite conclusion. Here is what an overlay actually is, why it fails, and what real remediation looks like instead.
What is an accessibility overlay?
An accessibility overlay, sometimes called a widget, toolbar, or plugin, is a piece of JavaScript you paste onto your website. When a visitor loads a page, the script runs in their browser and tries to detect and patch accessibility problems on the fly: adjusting contrast, guessing at image descriptions, or reshaping how a screen reader sees the page.
The key point is what an overlay does not do: it does not change the HTML, CSS, and components that your site actually ships. The underlying code is unchanged. The overlay sits on top of it and attempts corrections in real time, every time, for every visitor. When the overlay guesses wrong, it can make a page harder to use than it was before, and assistive-technology users are frequently the ones who feel it first. Many experienced screen-reader users turn overlays off on sight.
The FTC accessiBe order
In April 2025, the United States Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1,000,000.
The FTC's complaint centered on accessiBe's marketing of its accessWidget product, including the claim that a single line of code could make a website compliant with the Web Content Accessibility Guidelines (WCAG). The Commission found that those representations were, in its words, "false, misleading, or unsubstantiated." The order bars accessiBe from claiming that its automated products can make any website WCAG-compliant unless it has evidence to support the claim, and it addresses deceptively formatted third-party reviews that failed to disclose the company's material connections.
The significance is not that one vendor was penalized. It is that a federal regulator formally rejected the core promise of the overlay category: that automation alone can deliver compliance.
Overlays do not stop lawsuits
The most direct evidence is what happens to sites that installed an overlay and were sued anyway.
The data
According to the AudioEye 2026 Web Accessibility Litigation Report, 38.5% of the businesses that faced accessibility lawsuits already had a widget-based accessibility solution in place. The widget did not prevent the claim, because plaintiffs could still show that core tasks such as forms, checkout, and navigation remained inaccessible. That figure is published by an overlay vendor about its own market, which is what makes it hard to wave away.
Murphy v. eyebobs
A blind plaintiff brought a putative class action against the eyewear retailer eyebobs in January 2021, in the US District Court for the Western District of Pennsylvania (No. 21-cv-00017). Public reporting on the case, and the complaint as published by a third party, record that the retailer had an accessiBe overlay installed and that the complaint alleged the overlay failed to give screen-reader users full and equal access to the site. The matter resolved in October 2021 by a consent decree setting out a remediation plan. The point for a buyer is narrow and it is the only point we draw: the overlay was in place before the suit was filed, and it did not prevent the suit.
Why the widget does not change what your server ships
An overlay runs in the visitor's browser after the page has already been delivered. It does not change the HTML your server ships, so the markup an expert witness downloads, and the markup a screen reader receives when the script is blocked, fails to load, or is switched off, is the unmodified original. A plaintiff evidences the page your site actually serves. That is why an overlay can change what a casual reviewer sees without changing what the record shows.
The practitioner consensus
The community-maintained Overlay Fact Sheet at overlayfactsheet.com (opens in a new tab) collects the technical evidence against overlay products and has been signed by more than 800 accessibility professionals, including people who build assistive technology and people who use it daily. It is the closest thing the field has to a settled position, and it is checkable in full rather than summarised here.
The pattern
Across these matters the reasoning is consistent. Accessibility is judged by whether a disabled person can actually complete the task, not by whether a widget is installed. An overlay that leaves the underlying barriers in place leaves the legal exposure in place too.
What real accessibility remediation looks like
Genuine accessibility is not a script bolted on at load time. It is a set of changes to the product itself, verified by the people the changes are meant to serve.
- Source-code fixes. Barriers are corrected in the HTML, CSS, and components your site ships, so the page is accessible before any assistive technology touches it.
- Semantic HTML. Using the right elements (headings, lists, buttons, landmarks) so structure and meaning are conveyed to assistive technology natively.
- ARIA where it is needed. Accessible Rich Internet Applications attributes fill gaps that semantic HTML cannot, applied deliberately rather than sprayed on automatically.
- Keyboard operability. Every interactive element reachable and usable without a mouse, with a visible focus indicator and a logical tab order.
- Screen-reader testing. Real checks with tools such as NVDA, JAWS, VoiceOver, and TalkBack, because automated scanning cannot confirm the lived experience.
- An ongoing remediation workflow. Findings tracked from open to fixed to verified, with a record of who did what, so accessibility survives the next release.
Automated tools are valuable for finding issues at scale, but even the best of them detect only a portion of barriers and can fix fewer still. Human judgment is not optional; it is the part that holds up.
How Pallas approaches it
Pallas is built for the model above: find the real issues, drive them to resolution, and keep the evidence.
Find
Scan and review
Automated scanning against WCAG 2.2, Section 508, and EN 301 549, combined with a workflow for the manual findings that automation cannot catch. Websites and documents. Section 508 and EN 301 549 mappings are derived from the WCAG scan; automated scanning covers the criteria that can be machine-tested, and a manual review checklist covers the rest.
Fix
Assign and track
Every finding gets an owner, a status, and a WCAG criterion. Assign work by team role, move issues through the lifecycle, and verify each fix through retesting instead of assuming it is done.
Prove
Evidence and reports
A tamper-evident audit trail with configurable retention, plus exportable reports. If a procurement team or a regulator asks what you did, you can show what you scanned, what you found, and what you fixed.
You do not have to take our word for it
The Overlay Fact Sheet is a community-maintained document, published at overlayfactsheet.com (opens in a new tab), that catalogues why overlays fail and collects the evidence.
It has been signed by more than 800 accessibility professionals, including contributors to the WCAG, ARIA, and HTML specifications and accessibility specialists from major technology companies and universities. Their shared conclusion is blunt: overlays do not deliver compliance, can interfere with the assistive technology they claim to help, and divert resources away from the real fixes. We link to it so you can check the evidence yourself.
Last updated: 15 September 2026.
See a real scan of your site
Free scan, no account needed. Your email is required so we can send the report. Paid plans use OAuth signup, no password, cancel anytime.