Web Accessibility in 2026: Why Overlay Widgets Won't Save You From a Lawsuit
US federal accessibility lawsuits hit 3,117 in 2025, up 27% year over year, and the EU's European Accessibility Act is now actively enforced. The bolt-on widget most sites installed to get ahead of it doesn't work, and courts are starting to say so.
Accessibility used to sit on the "nice to have" list, somewhere below the launch deadline and above the blog redesign. That list no longer describes reality. In the US, federal digital accessibility lawsuits reached 3,117 in 2025, up 27% from 2,452 the year before, and more than 5,000 when state-court filings are counted. In the EU, the European Accessibility Act has been actively enforced since 28 June 2025, and 2026 is the first full year national regulators are checking. Both tracks point at the same site: whatever's live on your domain right now.
The lawsuits aren't slowing down
The headline number understates the trend, because federal filings only tell part of the story: nearly 80% of accessibility claims now originate in state courts, which don't show up in the federal count at all. E-commerce carries the heaviest exposure, accounting for roughly 70% of ADA web cases, but no industry is exempt: any business collecting an email, taking a booking, or selling online is a plausible target. The underlying reason the numbers keep climbing isn't mysterious. Independent audits find that just 2% of webpages pass 70% or more of testable WCAG criteria, and 95.9% of top homepages fail outright. The pool of non-compliant sites is enormous, and it's the pool plaintiffs' firms are working through.
Europe caught up, and it applies more broadly than people assume
The European Accessibility Act (Directive (EU) 2019/882) sets its technical bar through EN 301 549, which maps directly to WCAG 2.1 Level AA. Enforcement began in mid-2025, and by 2026 the practical effect is visible: procurement teams asking vendors for conformance evidence, market surveillance authorities requesting audits, and accessibility statements getting scrutinized instead of rubber-stamped. Penalties vary by member state but can reach €3,000,000, and the scope isn't limited to companies headquartered in the EU: if you sell to EU consumers, the obligation follows the customer, not your office address. A US or UK business with European traffic is in scope even if it's never thought of itself as an EU company.
Why the quick-fix widget makes things worse, not better
Faced with that pressure, thousands of site owners installed an accessibility overlay: a JavaScript snippet promising instant compliance through a floating widget that adjusts contrast, font size, and a few ARIA attributes at runtime. It's an appealing shortcut, and it's failing in exactly the way critics warned it would. More than 1,000 businesses, over 25% of all digital accessibility lawsuits filed, were sued despite having an overlay installed; in May 2025 alone, 119 overlay-using defendants were named in new suits. In April 2025, the FTC ordered one of the largest overlay vendors to pay $1 million for falsely claiming its AI-powered tool could make any website WCAG compliant.
| Overlay Widget | Built-In (Engineered) Accessibility | |
|---|---|---|
| What it touches | Runtime DOM, after the page loads | Source HTML/markup itself |
| What scanners & screen readers see | Often unchanged underlying code | The actual fix, every time |
| Legal standing | Cited in 25%+ of 2025 lawsuits despite being installed | Addresses the WCAG criteria courts check |
| FTC/regulatory view (2025-26) | One major vendor fined $1M for false claims | No shortcut to misrepresent |
| Maintenance | New widget version, same underlying gaps | Fixed once, holds as the site evolves |
The technical reason is straightforward once you see it: overlays modify the page a browser renders after the fact, but automated scanners and most assistive technology read the underlying HTML the server actually sends. A widget that visually reorders focus or injects an ARIA label at runtime often does nothing to the markup a scanner (or a screen reader parsing the DOM before the script finishes) actually encounters. Worse, several rulings now treat an installed overlay as evidence the site owner knew accessibility was a problem and chose a superficial fix instead of a real one, which plaintiffs' attorneys read as a weaker position than doing nothing at all.
What actually passes: it's a code problem, not a plugin problem
WCAG 2.1 AA compliance is a list of testable, specific requirements, and nearly all of them live in how a page is built rather than what's bolted onto it afterward: semantic HTML so a screen reader can identify headings, lists, and landmarks instead of guessing from visual layout; full keyboard operability, meaning every interactive element (menus, modals, custom sliders) works without a mouse and never traps focus; color contrast ratios of at least 4.5:1 for body text; meaningful alt text on informative images and empty alt attributes on decorative ones; and form fields with real programmatic labels, not placeholder text standing in for one. None of that can be patched in by a script running after the page loads. It has to be true of the markup itself.
Why this favors engineered sites over templates and widgets
This is the same pattern that shows up with Core Web Vitals and with structured data for AI search: work that has to happen at the code level is easy on a codebase built with intent and hard on one assembled from someone else's defaults. On a custom Next.js build, semantic structure, keyboard behavior, and contrast are design and engineering decisions made once, reviewed like any other code, and consistent across every page because there's one component library, not a stack of third-party widgets each making its own assumptions. On a page-builder or template site, accessibility usually gets addressed the same way SEO does: through a plugin trying to infer intent from markup that wasn't organized with that intent in mind, which is precisely the gap overlays exist to paper over and precisely the gap that keeps failing in court.
What to check now
Start with an honest baseline rather than a vendor's compliance badge: run an automated scanner like axe or WAVE against your top pages, then supplement it with an actual keyboard-only pass, because automated tools catch roughly a third of WCAG issues at best and miss most keyboard and screen-reader problems entirely. Fix what you find at the markup level, publish an accessibility statement that describes real, current conformance rather than aspirational language, and treat new pages as guilty until proven compliant rather than retrofitting once a year. None of this is exotic work, and none of it is optional anymore. The sites absorbing the current wave of lawsuits and enforcement action are, almost without exception, the ones that tried to buy their way past the requirement instead of building to it.