Digital accessibility lawsuits are not a niche legal risk anymore — they're one of the most predictable and fastest-growing categories of litigation against businesses with a website. Federal ADA Title III web accessibility lawsuits hit 3,117 in 2025, a 27% jump from 2024, and when state court filings are counted, total 2025 filings exceeded 5,000. UsableNet's mid-2026 tracking projects roughly 6,176 digital accessibility lawsuits for the full year — another record, and nearly 20% above 2025.
If you run a website — especially one that sells anything — this is worth understanding in concrete terms, not just as background legal noise. This post covers what WCAG actually is, what the current legal standard requires, who's getting sued, and what meaningfully reduces risk versus what doesn't.
What WCAG actually is
WCAG (Web Content Accessibility Guidelines) is a set of technical standards published by the W3C describing how to make web content usable by people with disabilities — visual, auditory, motor, and cognitive. It's organized around four principles, often remembered by the acronym POUR:
- Perceivable — content must be presentable in ways users can perceive (e.g., alt text for images, captions for video, sufficient color contrast).
- Operable — interface components must be usable via keyboard alone, not just a mouse, with no time limits that can't be extended or turned off.
- Understandable — text is readable, pages behave predictably, and forms provide clear error identification.
- Robust — content works reliably across assistive technologies like screen readers, now and as those technologies evolve.
WCAG defines three conformance levels — A (minimum), AA (mid-range, the level almost all legal and regulatory standards reference), and AAA (the highest, rarely required in full because some AAA criteria conflict with certain types of content). When you see "WCAG 2.1 AA" or "WCAG 2.2 AA" referenced in a lawsuit or a compliance requirement, that's the level in question.
In October 2025, WCAG 2.2 was formally approved as an international standard (ISO/IEC 40500:2025). WCAG 2.2 is backward-compatible with 2.1 — it adds new success criteria (like requiring visible focus indicators and larger touch targets) without removing anything from 2.1. That backward compatibility is why most accessibility consultants now recommend targeting WCAG 2.2 AA even though the current legal baseline in the U.S. still points to 2.1 AA.
The current legal standard in the U.S.
The Department of Justice published a rule in April 2024 formally defining WCAG 2.1 Level AA as the compliance standard for ADA Title II — the part of the ADA covering state and local government websites and mobile apps. That's the clearest, most explicit regulatory anchor point that currently exists for what "accessible" legally means for a public-sector digital property.
Timelines for that Title II requirement have shifted. The DOJ issued an interim final rule in 2026 giving local governments more time: large public entities (population 50,000+) now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028.
Title III of the ADA — the part that covers private businesses, not government — has no equivalent DOJ-published technical standard. This is the part that trips people up: there's no single regulation that says "your private business website must meet WCAG 2.1 AA." Instead, courts across nearly every circuit have converged on WCAG 2.1 AA (increasingly 2.2 AA in practice) as the de facto benchmark they reference when evaluating whether a website was "accessible" under the ADA's general nondiscrimination requirement. So even without an explicit statute naming WCAG for private businesses, it functions as the practical standard plaintiffs' attorneys, defense attorneys, and judges all point to.
Who's actually getting sued
The pattern in the lawsuit data is consistent year over year: e-commerce dominates. Roughly 70% of ADA web accessibility cases target e-commerce sites — retailers, DTC brands, and any business selling products or booking services online. That's not surprising; e-commerce sites have the most interactive surface area (product filters, checkout flows, forms, image-heavy catalogs) where accessibility failures are both common and easy for a plaintiff's tester to document.
One statistic worth sitting with if you've already invested in accessibility tooling: about 1 in 4 sued sites (24.9%) already had an overlay or accessibility widget installed at the time they were sued in 2025. That doesn't mean overlays are worthless, but it's a strong signal that bolting a third-party widget onto a non-compliant site is not, by itself, a defense — courts and plaintiffs' firms have gotten savvier about testing past the widget to the underlying markup.
And the scale of the underlying problem explains why lawsuit volume keeps climbing: studies consistently find that roughly 94.8% of websites fail basic accessibility checks when tested against WCAG success criteria. With that large a pool of non-compliant sites and a well-established, repeatable legal playbook (a demand letter, often followed by a suit if unresolved), the incentive structure for plaintiffs' firms to keep filing is strong.
Common accessibility failures that trigger lawsuits
Most lawsuits aren't citing exotic, hard-to-fix problems. The recurring issues across accessibility audits and litigation are mundane and mechanical:
- Missing or inaccurate alt text on product images, icons, and buttons — so screen reader users can't tell what they're looking at or clicking.
- Insufficient color contrast between text and background, which affects users with low vision far more broadly than most teams expect.
- Keyboard traps and unreachable elements — modals, dropdown menus, and custom-built widgets that can only be operated with a mouse.
- Missing form labels — inputs without a programmatically associated label, so a screen reader announces "edit text" instead of "email address."
- No visible focus indicator — a user tabbing through the page has no way to see where they currently are, which is one of the new explicit requirements added in WCAG 2.2.
- Inaccessible custom components — carousels, accordions, and date pickers built from scratch without the ARIA roles and keyboard behavior that make them work with assistive technology.
None of these require rebuilding a site from scratch. They require a genuine audit — automated scanning plus manual testing with a screen reader and keyboard-only navigation — followed by fixing what's actually broken.
What reduces risk, and what doesn't
What helps:
- A real WCAG 2.1/2.2 AA audit, combining automated tools (which catch roughly 30-40% of issues) with manual testing, since many of the most commonly litigated issues — keyboard operability, logical focus order, meaningful alt text — require a human to actually evaluate.
- Fixing issues in the underlying HTML/CSS/JS rather than layering a script on top that attempts to inject fixes at runtime.
- An accessibility statement and a clear, monitored contact channel for users to report barriers — this shows good-faith effort and gives you a chance to fix issues before they become a demand letter.
- Ongoing monitoring, since accessibility isn't a one-time project — every new feature, page template, or third-party embed (including chat widgets) can reintroduce failures.
What doesn't reliably help:
- Installing an overlay widget and treating it as compliance. As the 24.9% statistic shows, plaintiffs' firms test past these regularly, and several overlay vendors have themselves been named in complaints for making false accessibility claims.
- Relying solely on an automated scanner's "pass" result — automated tools cannot evaluate most of the criteria that actually end up cited in lawsuits (meaningful alt text, logical reading order, keyboard operability of custom widgets).
What an audit and remediation actually cost
For businesses trying to budget this realistically, published pricing from accessibility firms gives a reasonable range. A WCAG audit typically runs $1,250–$2,750 for most small-to-midsize sites, with manual audits (the kind that actually catches the issues courts care about) running $1,500–$5,000 depending on site complexity; a single-page or homepage-only audit can be done for $250–$850 if you need a quick baseline read before committing to a full engagement.
Remediation — actually fixing what the audit finds — is typically priced per page, in the range of $350–$550 per page. A 10-page marketing site might run roughly $3,500 for the audit and another $5,000–$5,500 for remediation. Larger, more complex sites with custom components, e-commerce checkout flows, or dynamic content cost proportionally more, since custom-built widgets (carousels, filters, modals) take more manual developer time to fix correctly than static content.
Many businesses handle remediation with their own development team once the audit hands them a prioritized list of issues, supplementing with outside technical support hours (commonly billed around $195/hour) for the trickier ARIA and keyboard-navigation fixes.
The remediation process, step by step
A properly run remediation project follows roughly this sequence:
- Audit — a full WCAG 2.1/2.2 AA audit with code access, combining automated scanning with manual keyboard and screen-reader testing. This step produces the actual list of what's broken, not a guess.
- Remediate — issues get split into developer tickets (code-level fixes like ARIA roles, focus management, form labels), content-editor tasks (alt text, heading structure, link text), and vendor outreach for any third-party embeds or widgets you don't directly control the code for.
- Validate — every fixed item gets individually re-tested, followed by a fresh pass across a sample of pages to confirm the fixes didn't introduce new problems, which happens more often than teams expect when accessibility fixes are rushed.
- Document — publish an accessibility statement describing what was tested, what was fixed, and a clear channel for users to report remaining barriers. This step matters for legal posture as much as for users — it demonstrates a documented, good-faith effort rather than silence.
- Monitor — add automated accessibility checks into the deployment pipeline (many teams use tools like axe-core in CI) and schedule periodic manual audits, since new pages, new content, and new third-party scripts can silently reintroduce issues that were already fixed once.
Skipping step 5 is one of the most common reasons sites that passed an audit still end up in a lawsuit eighteen months later — accessibility is a continuous practice, not a one-time certificate.
Where this connects to AI-driven widgets
Businesses adding AI-powered features to their site — chatbots, lead qualifiers, document upload tools — should treat accessibility as part of that build, not an afterthought layered on later. A support bot or lead qualifier widget that isn't keyboard-operable, doesn't announce itself properly to a screen reader, or traps focus when it opens is exactly the kind of third-party component that shows up in an accessibility audit as a new liability, even if the rest of the site is otherwise compliant. If you're evaluating a widget vendor — including something like Techvea's Support Bot or Lead Qualifier — it's reasonable to ask directly whether the widget itself has been tested for keyboard navigation and screen reader compatibility, since that widget becomes part of your site's accessibility surface the moment it's embedded.
The bottom line
Web accessibility litigation isn't slowing down — 2026 is on pace to be the highest-volume year on record, and e-commerce remains squarely in the crosshairs. The legal standard private businesses are functionally held to is WCAG 2.1 AA today, trending toward 2.2 AA as the practical target given its backward compatibility and growing adoption. The businesses that actually reduce their risk are the ones doing real audits and fixing root causes in code — not the ones installing a widget and calling it done.
Sources:
Get new posts as they publish
No spam — just the next post, straight to your inbox.