Does an accessibility overlay widget make a site WCAG or ADA compliant?

No. An overlay runs a script that tries to patch accessibility issues through the DOM and CSS after the page loads, but it doesn't fix the underlying code - non-semantic HTML, keyboard traps, or forms missing proper labels stay exactly as they were. The FTC found that accessiBe misrepresented its widget as bringing sites to full WCAG compliance.

So what actually reduces the legal risk?

Fixing the code itself to meet WCAG 2.1 Level AA - proper input labels, full keyboard navigation, correct color contrast, and real alt text for images - tested manually with an actual screen reader, plus ongoing maintenance as the site changes. It's a more thorough one-time process, but it fixes the actual problem instead of masking it.

← All Articles

Accessibility · Oct 23, 2026 · May I

Accessibility Overlay Widgets - Do They Protect You From a Lawsuit, or Raise Your Risk

Q: If I install an accessibility widget, can I still get sued?

Yes. Per UsableNet's 2023 digital accessibility lawsuit report, lawsuits against websites using an overlay widget rose 60% that year, and about 30% of all digital accessibility lawsuits filed in the US targeted sites that already had an overlay installed. A widget doesn't take you off a plaintiff's target list.

Short answer: no. An accessibility overlay widget runs a JavaScript layer that patches how the page displays after it loads, but it doesn't fix the underlying code - which is why sites running these widgets keep getting sued. Per UsableNet's own lawsuit tracking, lawsuits against websites using an overlay widget rose 60% in 2023, and in January 2025 the US FTC fined accessiBe, the industry's leading vendor, $1 million for misrepresenting what its product actually does.

Why an overlay widget looks tempting

The pitch is simple: one line of code added to your site, and within minutes there's an accessibility button that opens a menu for text size, contrast, pausing animations, and so on. No dev project, no QA pass, no waiting. For a small business worried about a lawsuit and not sure where to start, it sounds like the easy way to close the issue - which is why this market is worth hundreds of millions of dollars a year.

What a widget actually does - and what it can't

An accessibility overlay is mostly a CSS and JavaScript layer that runs on top of the existing page and tries to change behavior through the DOM after it loads. It can bump font size or overall contrast. But it can't know the real meaning of an element on the page - it can't add an input label that doesn't exist in the source code without guessing wrong, it can't fix a keyboard focus trap caused by the underlying HTML structure, and it can't repair broken screen-reader navigation caused by a developer using a <div> instead of a <button>. Those are problems that have to be fixed at the source - in the code itself, not layered on top of it.

That's exactly what the US FTC found, formally. Per the settlement announced in January 2025, accessiBe advertised that its widget, accessWidget, brought a site to full WCAG compliance using artificial intelligence - while basic components like navigation menus, form fields, and image descriptions remained inaccessible in practice. accessiBe also paid for reviews published on third-party sites without disclosing they were paid placements, so they read as independent opinions. The company paid $1 million and agreed to stop this kind of misleading advertising (source: technologylaw.fkks.com).

The data - a widget doesn't take you off the target list

Per UsableNet's 2023 year-end digital accessibility lawsuit report, lawsuits against websites that had installed an overlay widget rose 60% that year, and about 30% of all digital accessibility lawsuits filed in the US targeted sites that already had an overlay running (source: accessibility.works). In other words, a widget doesn't just fail to protect you - plaintiffs' attorneys who specialize in this area sometimes read it as a signal that the business is aware of its accessibility obligations but chose a cosmetic fix instead of actually addressing the problem.

What actually reduces the risk

An accessibility audit of the code itself against WCAG 2.1 Level AA - not an automated scan alone, but manual testing with a keyboard and a real screen reader.
Fixing the source - proper input labels, correct heading hierarchy, compliant color contrast, and real alt text for images - not hiding the issue behind an external layer.
An honest accessibility statement that spells out what's been done, what's in progress, and a way to report an issue.
Ongoing maintenance - every new page or form added to the site needs the same check, not just the launch version.

That's the real difference between a site built in custom code and a site built on a template with a patch layered on top. When the code is written from the ground up by someone who knows the WCAG standard, accessibility is part of the structure - not a bandage applied at the end.

What definitely isn't a good idea

The most common mistake: installing a widget, getting a "100% accessible" badge from its vendor, and treating the issue as closed. That's exactly the impression the FTC found to be misleading. If a quote promises full compliance "in one click" or "within 48 hours," that's a red flag, not a selling point. Real accessibility is a process of testing and fixing code - not a product you install and forget.

Want a site built accessible from the ground up?

We build and audit custom-code websites against the WCAG standard - not a widget bolted on at the end, but accessibility that's part of the structure.

Get started