What an overlay is
An accessibility overlay is a script from a vendor that you add to every page of your site. Most do some mix of 2 things:
- A toolbar. A floating button opens a menu of settings: bigger text, higher contrast, extra spacing, a reading guide, sometimes a built-in “screen reader.”
- Automatic repairs. As each page loads, the script tries to patch problems in the code: guessing alt text for images, adding labels to buttons and form fields, adjusting how menus are announced.
The pitch is appealing, especially with an ADA Title II deadline coming: compliance in a day, for a monthly fee, without touching the site.
What it can change
To be fair, an overlay can change some things. A script can add a label where one is missing, if it guesses the right one. A toolbar can enlarge text.
But most of the toolbar repeats what people who need it already have. Browsers zoom. Phones and computers have built-in contrast settings, text sizing and screen readers, and the people who rely on them have them set up the way they like. A separate control panel on each website is one more thing to learn, not a fix.
What it can’t change
WCAG judges the page people actually get. In principle a script could repair a page completely. In practice, most success criteria call for human judgment that no script can make:
- Meaning. A script can tell you a picture shows “a chart.” It can’t say the chart shows the parks budget falling 12% over 3 years, or know that an image is decorative and should be skipped.
- Forms and processes. It can’t rewrite confusing instructions, fix error messages that don’t say what went wrong, or rebuild a permit application that only works with a mouse.
- Captions. It doesn’t caption your recorded videos or your live council meetings.
- Documents. PDFs, Word files and slide decks are web content under the Title II rule. A script running on your web page doesn’t repair a file someone downloads.
- Other domains. Payment portals, agenda systems and reservation tools often run on a vendor’s domain, where your overlay doesn’t load.
- Tomorrow’s content. Each new page and post is a new chance for the guesswork to miss.
In our experience overlays can also get in the way: scripts that change how a page is announced can conflict with the screen reader a visitor already uses. That makes the page harder to use for the very people it is meant to help.
What the government has said
The Justice Department. In its 2022 guidance on web accessibility and the ADA, the Department says automated checkers and overlays “can be helpful tools,” but that they “need to be used carefully,” and that a clean report “does not necessarily mean everything is accessible.” It recommends pairing automated tools with a manual check.
The Federal Trade Commission. In January 2025 the FTC filed a complaint and proposed order against accessiBe, which sells an overlay called accessWidget. The complaint alleged that the company’s claims that accessWidget could make any website WCAG-compliant were false, misleading or unsubstantiated, and that the company dressed up its own marketing as independent reviews. In April 2025 the Commission approved the final order, 3 to 0. accessiBe must pay $1 million and may not claim its automated products can make any website WCAG-compliant, or keep it compliant over time, without evidence to back that up.
Note what the FTC case was about: a vendor’s advertising. It didn’t rule on any particular website. But it puts on the public record what accessibility practitioners have said for years: a widget is not a substitute for accessible content.
The Title II rule. The rule for state and local governments sets WCAG 2.1 Level AA as the standard for your web content and mobile apps, including content vendors provide for you. It allows a separate accessible version of inaccessible content only in very limited circumstances. Nothing in it treats an overlay as a way to meet the standard.
What to do instead
The work is less mysterious than the overlay pitch makes it sound:
- Audit what you have. Combine automated scans with manual testing by keyboard, zoom and screen reader, and rank what you find by how many people it stops. Start with the services people use most.
- Fix the source. Most problems live in a handful of templates and components. Fix the header, the navigation and the form styles once, and hundreds of pages improve at the same time.
- Deal with documents. Turn the forms and notices people rely on into web pages where you can, tag the PDFs you keep, and stop posting scans.
- Hold vendors to the standard. Put WCAG 2.1 AA, and ideally 2.2 AA, in your contracts, with testing and a remediation warranty. Our guide to writing an accessible website RFP has sample language.
- Train the people who post. Headings, link text, alt text and accessible documents are skills, and the basics take an afternoon to learn.
- Give people a way to tell you. Publish an accessibility statement with a contact for reporting problems, and answer quickly. The Justice Department’s guidance lists this among the basics.
If you already pay for one
Don’t count the overlay toward compliance, and don’t cite it in your accessibility statement as the reason your site is accessible. Fix the underlying problems first, then decide whether the toolbar adds anything your visitors’ own devices don’t. Check the renewal date so you are not locked into another year while you do.
This article is a plain-language summary, not legal advice. Sources: ADA.gov web guidance, ADA.gov fact sheet on the Title II web rule, FTC press releases of January 3, 2025 and April 22, 2025, W3C on evaluation tools.
Prepared by Awesome Cause with AI assistance. These guides provide planning advice; project scope and estimates are agreed individually.
