No. They cannot.
That is the short answer to the question. The long answer is more useful, because the reasons matter, and so does what you should do instead.
This post explains what overlay widgets actually do, what compliance actually requires, and how to use the two together honestly.
What an overlay widget is
An overlay widget is a small block of JavaScript you add to your website. It loads a floating button. When a visitor clicks the button, a panel opens with toggles: bigger text, higher contrast, dyslexia font, mute sounds, slow down animations. The visitor picks the controls they need, and the widget applies them to your page.
That is the whole product. It is a user preference layer. It runs in the visitor's browser, on top of whatever HTML you already have.
What WCAG compliance actually requires
The Web Content Accessibility Guidelines, version 2.1 at level AA, contain fifty success criteria. They cover things like:
- Every image must have a meaningful text alternative.
- Every form input must have a programmatically associated label.
- Every interactive element must be reachable by keyboard.
- Focus order must follow a logical sequence.
- Colour contrast must meet specific ratios.
- Headings must follow a sensible hierarchy.
- Page structure must use proper landmarks.
- Custom widgets must expose correct ARIA roles, states, and properties.
To be WCAG 2.1 AA compliant, your underlying HTML, CSS, and JavaScript must satisfy all fifty. An auditor checks the source. A screen reader reads the source. A keyboard user navigates the source. None of them care what your overlay widget does on top.
Why overlay widgets cannot deliver compliance
Three reasons, in order of importance.
The widget runs after the page loads
Search engine crawlers, screen readers in headless mode, and accessibility audit tools typically read your page before any third-party JavaScript executes. Anything the widget would have changed is invisible to them. Your alt text is still missing, your form labels are still wrong, your focus order is still broken, regardless of what the widget would have done if it had been allowed to run.
The widget cannot fix structural problems
Suppose your homepage has a div styled to look like a button. Visually it works. To a keyboard user it does not exist. An overlay widget can change the colour of text inside that div. It cannot turn the div into a real <button> element. It cannot give it a role="button" and the right tabindex and the right keyboard handlers. Those have to be in your code.
The same applies to forms with no labels, images with no alt text, links with no accessible names, and any custom dropdown that is not built with proper ARIA. The widget operates on the surface. The compliance gaps are in the foundation.
The widget can introduce its own accessibility problems
This is the part that gets overlay vendors sued. A widget that injects a non-standard menu, traps keyboard focus inside its panel, or speaks aloud unprompted can degrade accessibility for the users who already had it working. Several class actions filed against overlay vendors in 2022 and 2023 cited exactly these failures.
In January 2024, the US Federal Trade Commission settled with AccessiBe for $1 million over deceptive marketing claims that its AI-powered overlay could make websites WCAG and ADA compliant. The settlement bars AccessiBe from making such claims and from formatting paid endorsements as independent reviews.
So what is the widget actually good for
Real things. Useful things. Just not compliance.
A visitor with low vision can bump up the font size everywhere on your site without hunting for that one zoom setting in their browser. A visitor with dyslexia can swap to OpenDyslexic in one click. A visitor in a noisy office can silence your hero video's autoplay audio. A visitor with photosensitive vestibular issues can pause every animation on the page.
These are real accommodations for real users. They make your site nicer to use for people who would otherwise struggle. That is worth doing for its own sake, regardless of compliance.
How to actually become WCAG compliant
The honest path has four steps.
Step 1: Audit your current site
You can do this manually with browser dev tools and a screen reader, with an automated tool such as axe DevTools or WAVE, or by hiring a certified accessibility auditor for a manual review. Most teams should start automated and graduate to manual.
AriaWAI ships a built-in WCAG scan on every paid plan. It is not a substitute for a manual audit, but it catches the common issues and ranks them by severity.
Step 2: Fix the structural issues first
Tackle the violations in this order:
- Critical: missing alt text, form labels, keyboard traps, focus invisible.
- Major: colour contrast, heading hierarchy, link text, ARIA misuse.
- Minor: redundant landmarks, page title issues, language attributes.
Each fix lives in your codebase, your CMS, or your component library. The widget never enters this stage.
Step 3: Document your conformance level
If you have a procurement team or sell to one, you will eventually need a Voluntary Product Accessibility Template, also called a VPAT or Accessibility Conformance Report. This is a structured document that describes which WCAG criteria your product meets. AriaWAI's Pro plan generates one from your scan results.
Step 4: Add an overlay widget for genuine user benefit
Once your underlying markup meets WCAG, add the widget for the legitimate reasons in the previous section. Visitors who want bigger text get bigger text. Visitors who want high contrast get high contrast. Your compliance posture is solid because of the work in steps 2 and 3, not because of the widget.
Why some vendors keep claiming otherwise
Two reasons. The first is that the marketing message "one line of code makes you compliant" is much easier to sell than "audit your site, fix the problems, document the result, then add a widget for genuine user choice." The second is that, until recently, regulators rarely pursued the false claim.
That is changing. The FTC settlement was the most visible action, but it follows a sustained campaign by accessibility advocates, several class action lawsuits filed by blind plaintiffs against overlay-using sites, and public statements from leading accessibility organisations including the Web Accessibility Initiative and WebAIM.
The current consensus among accessibility professionals is unambiguous: overlay widgets do not deliver compliance, and vendors that say they do are misrepresenting the product.
Where AriaWAI lands
AriaWAI sells an overlay widget. We have never claimed it makes a site compliant, and we never will. The product description is "give visitors the controls they need to adjust your site to their preferences, while you fix the underlying markup so your site is genuinely accessible." That is what an overlay widget actually does. We sell it for what it is.
If a vendor tells you their widget will make you WCAG compliant, ask them to put that promise in writing alongside an indemnification clause. Most will not. The ones that already have, like AccessiBe, are the ones who got fined.
What to do this week
If you have an overlay installed already, keep it. It still helps users. But schedule a real audit of your site this quarter, fix what comes back, and document the result.
If you are about to install an overlay because someone told you it would make you compliant, install it anyway, but only after you have done the underlying work. That sequence is the only one that survives an actual lawsuit.
If you are looking for an overlay vendor that will tell you the truth, you found one.