The pitch usually arrives by email or in a plugin directory: add one line of code, a small wheelchair icon appears in the corner of your site, and the site becomes accessible overnight. Some versions promise ADA protection. Some offer a monthly plan. If you have just read about website lawsuits, it sounds like exactly what you need.
Accessibility overlays are worth understanding before you buy one or decide what to do with the one you already have. This post explains what they do under the hood, which problems they cannot reach, why so many disabled users and practitioners object to them, and what the alternative looks like in practice.
How accessibility overlays work under the hood
An overlay is third-party code that loads on top of your existing pages. It usually has two parts.
The first is a toolbar: the floating button that opens a panel of options such as bigger text, higher contrast, a readable font, highlighted links, paused animations or a built-in text-to-speech voice. The visitor changes settings, and the script restyles the page for them.
The second is a repair script that runs in the visitor’s browser each time a page loads. It scans the page and tries to patch what it finds: adding guessed alt text to images, inserting ARIA attributes, adding labels it infers from nearby text, changing how certain elements are announced. Some vendors describe this part as automatic or AI-driven remediation.
Neither part of accessibility overlays changes your site’s actual files. The theme, the plugins, the content in your database and your PDFs stay as they were. The overlay rewrites the page after it arrives, in each visitor’s browser, every time.
Do accessibility widgets work for the people they are meant to help?
Often they duplicate tools those visitors already have, and sometimes they get in the way.
Someone who is blind and uses a screen reader such as NVDA, JAWS or VoiceOver already has a screen reader. They do not need a second voice built into your page, and an extra toolbar is one more control to tab past. Someone with low vision has usually set up zoom, high contrast or a magnifier at the operating system or browser level, configured the way they like it across every site. A per-site panel with its own settings is less useful than the setup they arrived with.
The repair script is where the bigger trouble sits. Guessing is risky. An image of a product labeled by a machine as “a person holding an object” is not a useful description. ARIA added in the wrong place can make a working control sound broken, or announce a menu as a button that does nothing. When the guess is wrong, the visitor hears something misleading, and you have no idea it happened because the error lives only in their browser.
If a visitor’s own assistive technology already works well on a clean page, the overlay can only add noise to it.
Barriers that sit outside the script’s reach
Even a well-behaved overlay is limited to what it can see and safely change in a loaded page. A great deal of accessibility work sits outside that reach:
- Meaningful alt text. Only someone who knows why a photo is on the page can describe it properly. Is it a decorative background, or the floor plan a client needs?
- Keyboard behavior built into the theme. A dropdown menu written to open only on mouse hover, or a pop-up that traps focus, usually needs its JavaScript rewritten, not patched over.
- Forms. Clear error messages, sensible grouping, instructions before the field rather than after a failed submit. These are design and content decisions.
- Captions and transcripts. A script cannot produce accurate captions for your video or a transcript of your podcast.
- Documents. PDFs, Word files and scanned menus linked from the page are untouched.
- Third-party embeds. Booking widgets, payment fields and maps loaded in iframes are often out of the script’s reach.
- Content structure. If headings were chosen for their size, the overlay has no way to know what the outline should have been.
WCAG 2.2 AA, the benchmark that demand letters and audits use, is written about the page people receive. Many of its criteria, such as 1.1.1 Non-text Content, 1.3.1 Info and Relationships or 2.4.6 Headings and Labels, depend on meaning and judgment rather than on attributes a script can add.
Why advocates object, and what the FTC did
Disability advocates and many accessibility practitioners criticize overlays. Their objections are gathered in the Overlay Fact Sheet, an open letter that practitioners and advocates have signed. The core points are the ones above: overlays do not fix the underlying code, they can interfere with assistive technology, and the marketing often overstates what they achieve.
There is also a practical point owners care about. Sites that run overlays have still received demand letters and been sued. Having the toolbar on the page did not, on its own, settle the question of whether people with disabilities could use the site.
Regulators have noticed too. The Federal Trade Commission brought an action in 2025 against accessiBe, an overlay vendor, over marketing claims the agency considered misleading. That case concerned one company and is on the public record. The wider lesson is to read every vendor’s promises with the same care. A product that claims instant compliance is making a promise no tool can back up.
What owners usually do instead
The alternative is duller to sell and works better: change the site itself, so the improvement is in the theme, the templates and the content and reaches every visitor whether or not any toolbar loads. In practice that means testing with the overlay switched off (otherwise you are testing the vendor’s patches, not your site), then repairing what the test found in the code and in the editor. Our page on fixing the issues an audit finds describes that stage.
A quick way to see the gap for yourself: open your contact page in a private browser window with the widget blocked, or ask your developer to switch it off on a test copy of the site. Then press Tab through the form. Whatever you meet there is what the script was papering over, and what a visitor gets whenever the script loads late or fails.
If you have an overlay installed today, there is no need to rip it out this afternoon, and it should not stay your only plan either. Taking one off in the right order (fixes first, removal last) is its own job, covered on our page about replacing an overlay with real fixes.
A few honest exceptions
Is there ever a place for a toolbar? A preference panel that only changes text size or spacing, sold honestly as a convenience and installed on a site that has already been fixed, does little harm. The problem is not the existence of a font-size button. It is the claim that the button, or a script behind it, replaces the work.
The same goes for scanning tools. A checker that reports issues for a person to fix is useful. A script that silently rewrites your pages and calls the job done is a different thing. When a product blurs the two, ask the vendor exactly which WCAG criteria it fixes in your files, and which it only changes in the browser.
For the legal side of this question, including how the ADA applies to business sites in general, read our plain guide to ADA requirements for websites. It is general information, not legal advice, and a lawyer should handle any letter or lawsuit. For the other ideas that often travel with the overlay pitch, see common website accessibility myths, corrected. Audits, fixes and monitoring are described together on our hub of accessibility services for US businesses, if you want the wider view.
Frequently asked questions
What should I ask a vendor who is selling me an overlay?
Ask which WCAG success criteria the product fixes in your own files and which it only changes in the visitor’s browser, what visitors get if the script fails to load, and whether the contract or marketing promises compliance or legal protection. A vendor who cannot answer the first question clearly has told you what you need to know.
Are all accessibility plugins overlays?
No. Some WordPress plugins are checkers that scan your pages and list issues for a person to fix, which is useful. Others add small, specific fixes such as a skip link. Overlays are the ones that add a toolbar or a repair script and claim to make the whole site accessible automatically. Read the description to see which kind you have.
Does the toolbar help people with low vision?
Usually less than you would expect. People with low vision tend to rely on zoom, magnifiers and contrast settings built into their device or browser, set up once and used everywhere. A site that reflows properly when zoomed in and has enough contrast helps them more than a per-site panel.
What did the FTC do about overlays?
The agency brought an action in 2025 against accessiBe, an overlay company, over product claims it said were misleading. The action concerned that company only. For owners, the practical lesson is to be skeptical of any product that promises accessibility or legal protection automatically.
If you want help moving from an overlay to fixes in the site itself, our ADA website compliance work covers the technical side: audit against WCAG 2.2 AA, fixes in the theme and content, and a record of what changed. Legal questions stay with your lawyer.
Next in this series: ADA vs WCAG: How the Law and the Standard Connect
