Is web accessibility the law now? What 2026's rules, lawsuits and overlay traps mean for your site

Which laws actually apply to your website?

Four overlapping regimes now reach almost any public-facing site, and they converge on one technical standard: WCAG 2.1 AA. In the United States, courts apply Title III of the ADA to websites as “places of public accommodation,” and although no federal regulation names a specific version of WCAG by statute, courts and enforcement agencies treat WCAG 2.1 AA as the benchmark (Level Access, 2026). In the European Union, the European Accessibility Act came into force on June 28, 2025, requiring e-commerce, banking, transport and other digital services to meet EN 301 549, which incorporates WCAG 2.1 AA (Accessibility.build, 2026).

The reach is wider than one country at a time. A US company with EU customers now faces dual exposure, and non-compliant products can be barred from EU markets — a duty that domestic deadlines do not soften (Level Access, 2026). Canada adds the Accessible Canada Act and Ontario’s AODA; the UK adds the Equality Act. As one litigation tracker puts it, accessibility laws may be written by individual states and nations, but a website has no borders — if you are online, you are operating in all of them at once (AudioEye, 2026). For most businesses the practical conclusion is simple: build to WCAG 2.1 AA as a floor, aim for 2.2, and you have addressed the standard every one of these regimes points to.

How likely is a lawsuit, really?

More likely every year, and no longer only for large brands. More than 5,000 web-accessibility lawsuits were filed across US federal and state courts in 2025 — 3,117 in federal court alone, up about 27% year over year and the second-highest annual total on record (Accessibility.build, 2026). The count has more than tripled since 2017 (Level Access, 2026). E-commerce is the prime target, named in roughly 70–78% of cases, because a checkout a disabled customer cannot complete is both easy to document and a lost sale (AudioEye, 2026). And the exposure is no longer only American: since June 2025 the EU’s European Accessibility Act extends the same WCAG-based duty to any business serving EU consumers, which our guide on the European Accessibility Act covers.

Two patterns make the trend sharper. First, repeat exposure: about 45% of 2025 federal filings named companies that had already been sued, often because they paid a settlement and never fixed the site (UsableNet via beaccessible, 2026). Second, the venue is shifting to state courts, where statutory damages bite — California’s Unruh Act carries a minimum of $4,000 per violation, and a single class action against Fashion Nova settled for $5.15 million (Level Access, 2026). AI-assisted complaints are lowering the cost of filing, which is widely expected to push numbers higher in 2026 (Blue Atlas, 2026). The 15-employee threshold people remember from ADA employment law does not apply here; Title III reaches businesses of every size.

Don’t accessibility overlay widgets make me compliant?

No — and the data now treats the overlay as a liability, not a shield. An overlay is the small icon, often a blue figure in a corner, that companies market as a path to compliance. In April 2025 the FTC finalized a $1 million order against accessiBe, permanently barring it from claiming its AI overlay can make any website fully WCAG compliant (Blue Atlas, 2026). That was a regulator stating plainly that the headline promise was deceptive.

The litigation data says the same thing from the other direction. Roughly 40% of organizations sued for accessibility in 2025 already had an overlay installed when the suit was filed (AudioEye, 2026); a separate count found 22.64% of first-half-2025 suits targeted sites with a widget in place (EcomBack via WCAGsafe, 2026). More than 600 accessibility professionals have signed a public statement that overlays do not meet legal requirements and frequently make the experience worse for the people they claim to serve (Blue Atlas, 2026). The reason is structural: a widget injects JavaScript on top of your existing code, so it cannot repair the underlying HTML, broken keyboard navigation, or flawed ARIA baked into the page. It paints over the problem a screen reader still has to walk through. We cover the overlay’s legal trap in depth — the FTC fine, the lawsuits, and what works instead — in our guide on whether accessibility overlays are a legal trap.

Then why does my automated checker say I’m 98% fine?

Because an automated checker only sees the part of accessibility a machine can measure — roughly 30 to 40% of WCAG. Automated tools are good at catching missing alt text, low-contrast color, and absent form labels. They cannot judge whether alt text is meaningful, whether focus order makes sense, whether a custom dropdown announces itself to a screen reader, or whether a video has accurate captions. Those judgments need a person and assistive technology (Level Access, 2026).

The scale of the gap is measurable. The WebAIM Million analysis of the top million home pages found that 94.8% still fail basic accessibility, averaging 56.8 detectable errors per page (WebAIM via beaccessible, 2026). Six issues account for 96% of all detected WCAG failures: low-contrast text (79.1% of pages), missing alt text (55.5%), missing form labels (48.2%), empty links (45.4%), empty buttons (29.6%) and missing document language (15.8%) (WebAIM via WCAGsafe, 2026). A green automated score that ignores the other 60% of the standard is not evidence of compliance — it is evidence of what the scanner could reach.

What does “accessible” actually require?

It requires that everyone can perceive, operate, understand and rely on your site — the four principles behind WCAG, often shortened to POUR. In practice, conformance comes down to a handful of disciplines that a careful build gets right by default: sufficient color contrast; real, descriptive alternative text on meaningful images; every form field with a programmatic label; a logical heading structure; full keyboard operability with a visible focus indicator; and components built from semantic HTML so assistive technology understands them. The most common failures above are not exotic — they are the basics, skipped. For the full, buildable version of those disciplines — organized by POUR, with the nine new WCAG 2.2 criteria and how to test them — see our WCAG 2.2 checklist.

This is why accessibility is a craft question before it is a compliance question. The six issues behind almost all WCAG failures are decisions made while building: which color goes on which background, whether an image gets alt text, whether a button is a real <button>. That last decision — a real element versus a <div> dressed up with ARIA — is the subject of our guide on when to use ARIA. Get them right at the source and the audit is green because the site is accessible — not because a widget is hiding the gaps from a scanner. The most common failure of all — low-contrast text, on 79% of pages — is a pure design decision; our guide on accessible design and color contrast covers how to get it right. And whether a control can be used without a mouse — keyboard operability and a visible focus indicator — is decided the same way; our guide on keyboard accessibility and focus covers it.

Why build accessibility in instead of bolting it on?

Because accessibility is a program you sustain, not a product you buy once — and building it in is the only version that holds. A site changes many times a day; an overlay or a one-time “accessibility project” cannot keep up, which is exactly why so many widget-equipped sites still get sued. The expert consensus, and the approach regulators reward, is education, testing and remediation from the start (Blue Atlas, 2026). When accessibility is part of how the site is built, conformance is the side effect of good work rather than a separate, fragile layer.

There is a defensive benefit too. A conformant site backed by a manual audit and documentation of ongoing effort is strong evidence if a demand letter arrives — and increasingly, courts and the DOJ want to see the site actually fixed, not a fine paid and the barrier left in place (Accessible.org, 2026). Built-in accessibility produces that record naturally; a bolted-on widget produces a receipt and a false sense of safety.

Isn’t accessibility just an extra cost?

No — it is the same work as building a good website, and it pays back on more than one axis. Accessible, semantic, well-structured HTML is the same substrate as the HTML that loads fast, ranks in search, and can be read by AI assistants. The heading order a screen reader follows is the heading order an answer engine parses; the alt text a blind user relies on is the alt text that describes your image to a crawler. We wrote about that machine-reading side in our guide to whether your site is readable by AI — it is the same page, made well, doing double duty.

The market case is just as direct. Around 1.3 billion people live with a disability, and the barriers that trigger lawsuits — an unlabeled checkout field, an inaccessible payment step — are the same barriers that lose conversions for everyone (beaccessible, 2026). The form is where accessibility, conversions and legal exposure meet most sharply; our guide on building accessible forms covers that surface field by field. Notably, 71% of businesses report concern about accessibility legal risk while only 43% allocate resources to it (accessiBe, 2026) — a gap that is itself the opportunity. And the arithmetic favors building it in: a settlement, attorney’s fees and rushed remediation after a lawsuit routinely cost more than getting it right during the build — before you count the customers a broken checkout quietly turned away. Spending on accessibility is not a tax on a finished site; it is part of building one that works, ranks and sells.

How do you prove your site is accessible?

You test it the way a disabled visitor would use it, and you keep the record. Run automated scans to clear the mechanical issues, then test manually: navigate the whole site by keyboard, run it with a screen reader, check focus order and that every interactive element announces itself. Document what you tested and what you fixed. That documentation is both the path to genuine conformance and the strongest defense if litigation arrives. The full method — the automated baseline, the keyboard pass, and the screen reader test step by step — is in our guide on how to test your website for accessibility.

This is the discipline we hold for our own work, in public — the sites we ship meet WCAG 2.2 AA by construction, and our home page audits itself in front of you. A studio that tells you accessibility is built, not bought, should be the proof of its own claim.

What changed in 2026, and what’s coming?

The rules tightened on several fronts at once, so the 2026 picture is worth holding in view. The European Accessibility Act’s June 28, 2025 deadline is now live, extending WCAG-based duties to private digital services across the EU. In the US, the DOJ’s Title II rule sets WCAG 2.1 AA for state and local government sites; on April 20, 2026 the DOJ pushed the largest entities’ deadline from April 2026 to April 2027, with smaller entities to 2028 — but the underlying ADA duty did not change, so public bodies stay exposed in the meantime (Accessibility.build, 2026). A parallel HHS Section 504 rule reached its in-force date of May 11, 2026, covering most hospitals, health systems and Medicaid agencies that receive federal health funding (Accessibility.build, 2026).

State courts are where the growth concentrates. Filings clustered in New York (31.6%), Florida (24.2%) and California (18.9%), and Illinois jumped about 746% year over year as plaintiff firms relocated there (DarrowEverett, 2026). The throughline for 2026 is steady: deadlines move, the duty does not, and the litigation keeps widening to new states and smaller defendants.

Who is protected — and why it’s more people than you think

Accessibility serves far more users than the word “disability” usually brings to mind — around 1.3 billion people live with a significant disability worldwide (beaccessible, 2026). That includes people who are blind or have low vision, who are deaf or hard of hearing, who navigate by keyboard rather than mouse because of a motor condition, and who depend on clear structure and plain language because of a cognitive or learning difference. Each group meets your site through a different path, and each is stopped by a different failure — a missing label, an absent caption, a keyboard trap, a wall of unstructured text. That last group — readers with a cognitive or learning difference — is served by plain language and predictable layout, the subject of our guide on cognitive accessibility and plain language.

The audience is wider still, because disability is often temporary or situational. A broken arm, bright sun on a phone screen, a noisy room without headphones, a slow connection — each puts an otherwise able-bodied person, briefly, in the same position as someone with a permanent impairment. Designing for the edge improves the experience at the center: the captions that serve a deaf user serve everyone watching with the sound off, and the keyboard support that serves a motor-impaired user serves the power user who never reaches for the mouse.

How do you get help without buying a trap?

Look for work, not a widget — a partner who tests and fixes the site, not a vendor who sells a script that hides the gaps. The signals are concrete. A real provider performs a manual audit against WCAG 2.1 or 2.2 AA, tests with actual assistive technology, and hands you findings mapped to specific success criteria rather than a dashboard percentage produced by a scan (Blue Atlas, 2026). They talk about remediating your code and they document what was done. They do not promise “full ADA compliance” from one line of JavaScript, because — as the FTC made clear — no overlay can deliver that.

Because we sell no overlay and resell no compliance widget, this advice costs us nothing to give straight: if a vendor’s central promise is instant compliance, treat that as the warning, not the feature. The honest version of this work is slower, lives in your real code, and produces a site that is accessible whether or not a scanner happens to be watching.

---

One last framing, because it is the whole idea in miniature. The mark in our name is an infinity, and accessibility is one loop within it: the same semantic, static, fast page that opens cleanly for a screen reader is the page that loads instantly, ranks in search, and can be quoted by an AI assistant. You do not add accessibility to a finished site any more than you add it to a finished building by taping a ramp to the stairs. You build so that everyone — and every reader, human or machine — was always able to get in.