You have probably seen the pitch. Add one line of JavaScript, a small accessibility icon appears in the corner of your site, and your ADA and WCAG problems are handled. Some vendors even attach a legal guarantee.
It is an appealing offer for a business that knows accessibility matters and does not know where to begin. It is also, in the form it is usually sold, not true. An accessibility widget (often called an accessibility overlay) is not the same thing as WCAG conformance, and buying one does not make your website ADA compliant. Here is the honest version.
What an accessibility overlay actually does
An overlay is a script that loads after your page and modifies it in the visitor’s browser. Most overlays offer two things.
First, a toolbar of visitor-facing controls: bigger text, higher contrast, a reading guide, sometimes a dyslexia-friendly font. These are real conveniences for some people.
Second, automated remediation. The script scans the page and attempts to patch problems it recognizes, such as adding a guessed label to an unlabeled button or an alt attribute to an image that has none.
The first part is genuinely useful to a subset of visitors. The second part is where the promise breaks.
Why automated remediation cannot get you to WCAG conformance
WCAG 2.1 AA has dozens of success criteria. Studies of automated testing tools consistently find they can detect only a minority of them, because most criteria require judgment rather than pattern matching.
Consider what “conforming” actually asks of a page:
- Alt text must describe the meaning of an image in context. A script does not know why the photo is there.
- A form must communicate what went wrong when it rejects input. A script cannot invent your validation logic.
- Focus order must follow the logical reading order. A script does not know your intent.
- Video needs accurate captions. A script cannot caption your audio.
- A custom component must announce its own state. A script cannot know what your widget is supposed to be.
An overlay can guess. Guessing produces confident, wrong output, which is worse than silence for somebody navigating by screen reader. This is the crux of the objection raised repeatedly by disabled users and accessibility practitioners: the automated “fix” frequently makes the experience worse than the original barrier did.
The part that surprises people: your code is still broken
An overlay sits on top of your site. It does not change your code. Whatever is broken underneath is still broken.
That has two consequences. The barrier remains for anyone whose assistive technology does not interact well with the overlay. And you have added a dependency: a third-party script that must load, on every page, before the “accessibility” exists at all.
There is also a practical legal reality worth stating plainly. Accessibility complaints and demand letters continue to be filed against websites that run overlays, and that pattern has been reported publicly for years. A widget in the corner is not a defense, because conformance is a property of the site, not of a script. (This is general information, not legal advice. If you have received a demand letter, talk to an attorney.)
Five questions to ask an accessibility widget vendor
If you are being pitched one, these are fair questions and the answers are clarifying.
- Does the product modify my source code, or only what the visitor’s browser renders?
- How does it decide what an image means when it writes alt text?
- Can it caption my video content? If not, how does that criterion get met?
- Which WCAG 2.1 AA success criteria does it explicitly not address?
- What exactly does the guarantee cover, and what has it paid out on?
A confident vendor will answer four and five directly. Question four is the important one: every honest tool in this space has a list, and a vendor claiming there is nothing on theirs is telling you something useful.
What ADA and WCAG conformance actually requires
The unglamorous answer is that accessibility is built, not bolted on. It starts at the design stage, which is why accessible web design is a decision you make before the first template is coded, not a plugin you add after launch.
An honest process looks roughly like this:
- Audit. A website accessibility audit that combines automated scanning with expert manual review and real assistive-technology testing (screen readers such as NVDA, JAWS, and VoiceOver), so you learn about the barriers a scanner cannot see. Each finding should be mapped to the exact WCAG 2.1 A or AA success criterion, or Section 508 standard, it fails.
- Prioritize. A ranked remediation list, because not every issue carries the same human cost. High-severity barriers get fixed first.
- Fix the code. Changes made in the site itself, so it is accessible with no script required. On a WordPress site that usually means theme, template, and plugin work by WordPress developers who build to WCAG 2.1 AA as a default, not an add-on.
- Test again. Including keyboard only and with a screen reader, by a person, not a scanner.
After that it becomes maintenance. Accessibility is not a state you reach. It is a state you keep. Every new page, template, form, and plugin is another chance to introduce a barrier, which is why conformance has to be part of how the site is maintained rather than a project that closed last year. Ongoing WordPress maintenance that includes an accessibility check is far cheaper than a second full audit.
Is there any place for an accessibility overlay?
The visitor-preference controls are fine on their own terms. If some of your audience values a contrast toggle or larger text, offering it does no harm, particularly when the site already meets its obligations without it.
What you should not do is buy one instead of doing the work, or treat the vendor guarantee as the end of your responsibility.
The short version
If accessibility could be solved by a single script, it would have been. It cannot, because most of what accessibility asks for is human judgment about meaning, order, and clarity. A widget cannot supply that.
Our accessibility audits are performed by IAAP-certified practitioners and pair automated scanning with manual review and real assistive-technology testing. You get a prioritized, plain-English list of what is actually wrong and what to fix first, plus training and documentation so your team can keep the site conformant on its own. If you have an overlay today and want to know where you really stand, that is a good place to start. Audit pricing is published, so there is no mystery about cost.
Frequently asked questions
Does an accessibility widget make my website ADA compliant?
No. An overlay widget changes what the visitor’s browser renders. It does not fix the underlying code, and it cannot meet the WCAG success criteria that require human judgment, such as meaningful alt text, accurate captions, and logical focus order. Conformance is a property of the site itself.
What is the difference between an accessibility overlay and an accessibility audit?
An overlay is a script that runs on top of your site and guesses at fixes in real time. An audit is a review of your actual code and content, combining automated scanning with manual expert testing and assistive-technology testing, that tells you exactly which WCAG or Section 508 requirements fail and how to fix them at the source.
Can I keep an overlay after my site has been remediated?
You can. The visitor-preference controls (contrast, text size, reading guide) are harmless once the site already conforms without them. Just do not rely on the overlay’s automated remediation or its guarantee as a substitute for fixing the code.
