Why websites with accessibility widgets still get sued

Websites with accessibility widgets get sued constantly. In 2024, more than 1,000 of the 4,000+ digital accessibility lawsuits filed in the US targeted companies that already had a widget installed, over 25% of all cases (UsableNet 2024 report). If the pitch you heard was "install this and the lawsuits stop," the filing data says the opposite.

I'm not a lawyer and this isn't legal advice. But the numbers below are public, the cases are public, and the pattern is hard to argue with. Let's walk through it.

The numbers, year by year

Start with 2024. UsableNet, which tracks these filings, counted over 4,000 ADA lawsuits related to digital properties. Over 1,000 of the defendants had an accessibility widget on their site when they were sued. Monthly widget-related filings ranged from 56 in January to 121 in June, so this wasn't a seasonal blip. Every single month, plaintiffs sued companies that had already paid for a widget (source).

Did 2025 change the trend? No. By mid-year, plaintiffs had filed 2,019 digital accessibility lawsuits, and companies using widgets were sued in every single month of the first half. UsableNet's midyear report put it bluntly: accessibility widgets continue to offer no legal protection to the companies that use them (UsableNet H1 2025 report).

By the end of 2025, the full-year picture was in: more than 5,000 digital accessibility lawsuits filed, with monthly filings against widget-equipped sites ranging from 95 to 155, peaking in July. The report's conclusion is worth quoting directly: "Monthly filing data shows no meaningful reduction in lawsuits against widget users" (UsableNet 2026 trends report).

Three years of data. Thousands of cases. No protective effect.

The case that made it obvious: Murphy v. Eyebobs

Numbers are one thing. A named case makes it concrete.

In 2021, Anthony Murphy, a screen reader user, sued the eyewear retailer Eyebobs over an inaccessible website. Here's the detail that matters: Eyebobs had accessiBe installed at the time. The overlay didn't prevent the suit. The complaint alleged the site failed to give screen reader users full and equal access, overlay and all, and accessibility experts who reviewed the situation described the overlay as ineffectual and possibly making things worse for screen reader users (Equal Entry's breakdown).

The case ended in an October 2021 consent decree (full document). And what did the court-approved settlement require? Not a better widget. It required the real work: an accessibility coordination team, regular audits, a retained accessibility consultant, employee training, and a commitment to WCAG 2.1. In other words, everything the overlay was supposed to let Eyebobs skip.

When settlements started ruling overlays out by name

It gets more pointed. In late 2021, LightHouse for the Blind and other plaintiffs settled a case against ADP, the payroll giant, over inaccessible workplace software. The settlement agreement includes this line: "overlay" solutions such as those currently provided by companies such as AudioEye and accessiBe "will not suffice to achieve Accessibility" (Lainey Feingold's overlay legal update).

Sit with that for a second. A negotiated legal settlement, signed by a major company, explicitly names two overlay vendors and says their products don't count toward the accessibility obligations in the agreement. ADP had an overlay installed. It got sued anyway, and the resolution wrote overlays out of the remedy.

And the regulatory side caught up in 2025, when the FTC ordered accessiBe to pay $1 million over compliance claims for its widget. I covered that in detail in the FTC settlement post, so I won't repeat it here.

Why widgets don't stop lawsuits

None of this is mysterious once you understand what an overlay actually is.

An overlay is a script that runs in the visitor's browser, on top of your existing pages. It tries to patch things after the fact: injecting ARIA attributes, tweaking contrast, adding a settings panel. Your actual code doesn't change. The missing alt text is still missing in your HTML. The unlabeled form field is still unlabeled in your template. The overlay just tries to guess at fixes at render time, for some users, in some browsers.

Now think about how these lawsuits start. A plaintiff, or a tester working with a plaintiff's firm, visits your site with a screen reader and runs automated scans. Both of those hit the real page. If the screen reader can't complete checkout, that's the experience, widget or no widget. If a scan finds two hundred WCAG failures in the markup, those failures are in the complaint. Many overlays can even be detected and toggled off in a second, and some complaints cite the overlay itself as an additional barrier because it interferes with the assistive technology setup the user already had.

So the widget is invisible exactly where it counts. The failures live in your code, the testing happens against your code, and the complaint quotes your code. I've written more about the mechanics in why accessibility overlays don't protect you.

What actually reduces risk

There's no magic here, just work that's smaller than most teams fear:

• Find the real failures. Scan your key pages against WCAG 2.1. The most common failures (contrast, alt text, form labels, link names, heading structure) are exactly what automated testing catches reliably, and exactly what shows up in complaints.
• Fix them at the source. In templates and components, one issue at a time, assigned to a person. A contrast fix in a design token repairs every page at once. A label added to a shared form component fixes every form that uses it. An overlay can never multiply a fix that way, because it never touches the source.
• Keep a record. Scan dates, findings, fixes, re-scans. If a demand letter arrives, a documented history of remediation is genuine evidence of effort. An invoice from a widget vendor is not, and after the Eyebobs and ADP outcomes, everyone involved knows it.

If you're currently paying for a widget and want to redirect that budget, we maintain honest comparison pages, including a UserWay alternative breakdown, that explain the detect-and-fix approach versus the overlay approach.

Where does BugPort fit? We're the first and third bullet: scans mapped to WCAG success criteria, findings turned into bug reports with element-level evidence, and re-scan history that shows your failure count going down over time. The fixing is still yours, and I won't claim any tool makes you compliant, because compliance lives in your pages, not in a product.

FAQ

Does installing an accessibility widget make lawsuits less likely?

The filing data doesn't show it. In 2024, over 1,000 suits named widget-equipped sites, and UsableNet's full-year 2025 report found "no meaningful reduction" in monthly filings against widget users, which ranged from 95 to 155 per month (source).

Has a court or settlement ever said overlays aren't enough?

Yes. The LightHouse v. ADP settlement states that overlay solutions such as those provided by AudioEye and accessiBe will not suffice to achieve accessibility under the agreement (source). And the Murphy v. Eyebobs consent decree required audits, training, and WCAG 2.1 work from a company that already had an overlay installed.

Should I remove my widget?

That's a judgment call for you and your counsel. Some complaints cite overlays as barriers, and the money usually does more good funding actual remediation. What the data does say clearly: don't treat the widget as your compliance program.

What do plaintiffs' testers actually check?

Broadly, the same things you can check yourself: screen reader navigation of key flows (finding products, forms, checkout) and automated WCAG scans of the underlying pages. That's why fixing the source code works and overlays don't. The tests hit the code, not the widget.

Want to see your site the way a tester would? Run a free WCAG audit on any page and get the real failure list, mapped to WCAG success criteria.