Someone on your team installed an accessibility widget. A sales email promised it would take care of compliance overnight, or the web host bundled it, or it went in the week a demand letter arrived because it was the quickest thing to do. Now there is a little round icon in the corner of every page, a monthly invoice, and a nagging question about whether it fixed anything. Sometimes the question gets sharper: a blind customer says the site became harder to use after it went in, or your lawyer asks what has really been changed.
This page is for organizations that want an accessibility overlay alternative: real changes to the theme, plugins, forms and content, tested by people, and a clean removal of the widget once those changes are in. It explains what overlays can and cannot do, why so many disability advocates object to them, how we take one off a WordPress site without leaving a gap, and what to tell staff and customers. It is part of our website accessibility services.
What an overlay or widget actually does on your site
An overlay is a script loaded on every page, usually from the vendor’s servers. It typically does two things. It adds a toolbar that lets visitors change text size, contrast, spacing or cursor size. And it runs automated code that tries to detect problems in your page, such as missing image descriptions or unlabeled buttons, and patch them in the browser as the page loads.
The toolbar part repeats features many visitors already have. People who need larger text, high contrast or a screen reader usually set that up in their own browser or operating system, where it works on every website, not just yours. The automated patching part is where the larger claims come in, and where the trouble starts.
So what does an accessibility overlay alternative look like? It is not a different product with a better toolbar. It is the ordinary, slower work of correcting the pages themselves: writing image descriptions that say what the picture shows, rebuilding a menu so the Tab key opens it, labeling every form field, and choosing text colors that pass contrast on their own. The result is less visible than a floating icon, and that is the point. Nobody has to find a button to get a usable page.
What a script running in the browser cannot fix
A script that reads your page after it loads can guess, but it cannot know what you meant. Consider a few everyday barriers:
- An image of your price list. A guessing tool might label it “document” or “text”. The prices stay unreadable to a screen reader user.
- A dropdown menu that only opens on mouse hover. Making it work with a keyboard means changing how the menu is built, which a patch layered on top often gets wrong or makes worse.
- A booking form whose errors appear silently. Announcing errors correctly depends on how the form plugin handles submission, not on decoration added afterward.
- A video without captions. Nobody can caption a video automatically and well without a human checking the words.
- A PDF menu or brochure. The widget usually does not touch documents at all.
- Brand colors that fail contrast. A toolbar can let one visitor switch to high contrast, but the page itself still fails criterion 1.4.3 for everyone who does not know the toggle exists.
There is also a conflict problem. Screen readers and other assistive technology already have their own ways of handling a page. When an overlay alters the page’s structure on the fly, users report hearing duplicated content, focus jumping or controls that behaved before the widget went in and no longer do. That is why our first step on any site with an overlay is to test with it switched off as well as on. We go into the technical side more fully in our explainer on how accessibility overlays work and where they fall short.
The criticism, and the FTC action, in plain terms
Overlays are widely criticized by disability advocates and by many accessibility practitioners. A large number of them have put their names to the Overlay Fact Sheet, a public statement that explains why these products do not deliver what they advertise and asks site owners not to rely on them. Many disabled users have also said plainly that they find overlays get in their way.
Two further facts matter for a business owner. First, having an overlay installed has not stopped sites from being sued over accessibility. Second, in 2025 the Federal Trade Commission took action against one overlay vendor, accessiBe, over misleading claims about what its product could do. We mention that because it is a matter of public record. It is not a judgment on every product in the category, and you should read what any vendor promises with the same care.
We are not lawyers and give no legal advice. If you are dealing with a demand letter or a lawsuit, an attorney should guide those decisions; our technical response to a demand letter sits alongside that advice, never in place of it.
Overlay versus real fixes: a side-by-side view
| Question | Overlay or widget | Fixes in the site itself |
|---|---|---|
| Where the change lives | In a script from another company, applied each time a page loads | In your theme, plugins and content, owned by you |
| Works if the script fails to load | No; the page reverts to its original state | Yes; the corrected code is the page |
| Image descriptions | Guessed by software | Written by someone who knows what the image is for |
| Keyboard menus, forms, modals | Patched on top, often unreliably | Rebuilt or corrected in the code that creates them |
| Videos and PDFs | Usually untouched | Captioned, remediated or replaced with web pages |
| Evidence of what was done | A vendor dashboard or badge | A findings report, change list and retest record |
| Ongoing cost | Subscription for as long as the script runs | Upkeep as part of normal site maintenance |
Real fixes do not mean nobody can ever change text size. Modern browsers and operating systems already offer zoom, larger fonts, high contrast and reading modes, and a site built to conform to WCAG 2.2 AA supports them properly. That is the user’s own toolbar, and it travels with them.
How our accessibility overlay alternative replaces the widget
The order matters. Pulling the widget off first and fixing later leaves your site worse documented than before. Leaving it on forever means paying for something that may be getting in your users’ way. We do it like this:
- Inventory. We find how the overlay is loaded: a WordPress plugin, a script pasted into the theme header, a tag manager, a page builder setting, or an option added by your host. Some sites have it loaded twice.
- Baseline audit with the widget off. We disable it on a staging copy (or, where there is no staging, only for our own test session) and audit the site as it really is, against WCAG 2.2 AA, with automated scans plus keyboard and screen reader testing. This is the same method as our full WCAG audit.
- Prioritized fixes. We correct the issues found, starting with anything that blocks a task: menus, forms, buttons, focus, headings, contrast, image descriptions. The work follows our standard accessibility remediation process.
- Retest. We test the fixed pages again, without the overlay, and record the results.
- Removal. Only then do we take the overlay out completely.
- Post-removal check. We confirm nothing was relying on it and that no leftover code remains.
Removing the widget safely, step by step
If you want to remove an accessibility widget yourself after fixes are in place, here is what a careful removal looks like on WordPress. We follow the same steps when we do it for you.
- Take a backup of files and database first.
- Find every place it loads. Check Plugins for an accessibility plugin, the theme’s header settings, any “header and footer scripts” plugin, your tag manager container and your host’s control panel. Search the page source in your browser for the vendor’s name to confirm.
- Remove, do not just hide. Deactivating a plugin is a start, but delete it afterward and remove any script tags by hand. A hidden toolbar can still load and run its code.
- Clear caches in your caching plugin, your host and any CDN, so old pages with the script are not still being served.
- Retest key pages by keyboard and with a screen reader to confirm nothing changed for the worse.
- Cancel the subscription with the vendor once you are sure, and keep the confirmation for your records.
Plugins sometimes leave settings in the database after deletion. Our guides on swapping out a WordPress plugin safely and cleaning up data a plugin leaves behind walk through both in more detail.
What to tell staff, customers and the board
Removing a visible widget can raise questions inside an organization, especially if leadership was told it handled accessibility. A short, honest explanation works well. Something like:
“We replaced the accessibility toolbar with direct improvements to the website itself. Our menus, forms, images and pages were tested by keyboard and screen reader and corrected where they fell short. Visitors who need larger text or higher contrast can use the settings in their own browser or device, which now work properly on our site. We will keep checking the site as it changes.”
For customer service staff, give them one sentence and one action: if a visitor reports trouble using the site, take their contact details, note the page and what they were trying to do, and pass it on promptly to whoever manages the website. That feedback loop is worth more than any widget.
Your public accessibility statement should change too. If it currently points to the widget, rewrite it to describe the standard you work toward, what was tested, any known limitations and how to report a problem. Our accessibility statement service helps with honest wording.
Deliverables, and the information we need to begin
When the project is complete you have:
- A record of where the overlay was loaded and confirmation it was removed.
- The baseline audit, run with the overlay off, listing each issue and its WCAG criterion.
- The fix log: what was changed, where and how it was verified.
- The retest results, and a list of anything still open, such as third-party embeds we do not control.
- A draft internal note and an updated accessibility statement, if you want them.
To start we need WordPress administrator access, hosting or staging access, tag manager access if one is used, the name of the overlay vendor and your renewal date (so you are not charged for another term you do not need), and a list of the pages and forms that matter most. If a lawyer is involved, tell us how they want updates shared.
Judging the result, and mistakes to avoid
A fair test is simple. With the widget gone, put your mouse aside and use the site with only a keyboard. Then try it with VoiceOver on a phone or NVDA on a PC. Can you reach the menu, submit the contact form, read the main pages? Compare that with what you found with the widget on, before the fixes. The report should let you do this page by page.
Mistakes we see:
- Swapping one overlay for another. Changing vendors does not change the approach.
- Removing it with no fixes behind it. The site is no better, and now also has no visible sign of effort.
- Trusting a “compliance score”. Free scanners and vendor badges measure only part of what matters; our post on what online compliance checkers really measure explains why.
- Leaving the statement unchanged. A statement that credits a removed widget is now inaccurate.
- Treating it as a one-time job. New content and updates bring new barriers.
If you are weighing do-it-yourself options, the testing tools are free and the W3C’s Web Accessibility Initiative explains the standards clearly. Many owners can fix their content: headings, link text, image descriptions. The theme, menus and forms usually need a developer.
Questions to ask any provider offering to replace an overlay
- Will you audit with the widget switched off, so we see the real state of the site?
- Which parts will be tested manually, by keyboard and with screen readers?
- If the theme or a plugin updates next month, what happens to your changes?
- Will you remove every trace of the overlay, including tag manager and cached copies?
- What will you document, and what will you say you cannot promise?
Be wary of anyone who answers the last question with a promise of compliance. Conformance to WCAG 2.2 AA is something you work toward and document, not a switch. Accessibility plugins of other kinds, such as checkers that flag issues in the editor, can be useful alongside real fixes; our comparison of WordPress accessibility plugin types separates the helpful ones from the overlays.
After the overlay: keeping the site accessible
The appeal of an overlay was that it seemed to take care of things forever. The honest replacement is a routine. Each WordPress, theme or plugin update, each new page and each new form can introduce a barrier. We recommend a short monthly check of key pages and forms, a keyboard and screen reader pass after major updates and a review of anything new before it goes live. That fits naturally into ordinary monthly WordPress maintenance, and it is how the work you paid for keeps paying off, long after the widget’s icon has disappeared from the corner of the screen.