Federal courts logged 3,117 ADA website accessibility lawsuits in 2025 — up 27% year over year, and over 5,000 once you add state filings. Meanwhile, the WebAIM Million 2026 report just showed 95.9% of homepages failing WCAG, reversing six straight years of improvement. The math is uncomfortable: lawsuits are accelerating, sites are getting worse, and most devs assume the April 2026 deadline extension bought them time.
It didn’t. Not for private businesses. Not for healthcare. Not for the average plaintiff firm running automated scans against your homepage. This guide is the five fixes that cover roughly 80% of what gets sites sued — with code, written for the person shipping the work.
The Deadline Moved. The Lawsuits Didn’t.
Four days before the April 24, 2026 Title II deadline took effect, the DOJ blinked. The Interim Final Rule pushed compliance for large public entities (50,000+ population) to April 26, 2027, and small entities to April 26, 2028. Headlines treated it as a reprieve. For most readers of this article, it was nothing of the sort.
Title II is the rule for state and local government. Private businesses have never been on that deadline — they’ve been getting sued the entire time under ADA Title III, which has no specific technical standard and no grace period. If you ship a public-facing site for a private company, the extension didn’t move your timeline by a day.
Healthcare is even less ambiguous. The HHS Section 504 web accessibility rule, which covers any entity receiving federal funds, still takes effect May 11, 2026. That one wasn’t extended.
And the technical bar matters. Title II points at WCAG 2.1 Level AA, not 2.2. WCAG 2.2 is best practice and worth targeting on new work, but be precise about what’s legally required where — confusing the two is how teams end up arguing about focus-appearance criteria when their forms still don’t have labels.
What actually drives the lawsuits isn’t a regulator. It’s a small pool of plaintiff firms running automated scanners against thousands of sites, plus a newer wave of pro se filers using AI tools to draft complaints. The scanners look for the same handful of errors every time. The good news: so can you.
What 95.9% of Sites Actually Get Wrong
The WebAIM Million 2026 report counted an average of 56.1 WCAG failures per homepage. That number sounds catastrophic until you look at the distribution: it’s heavily skewed. A small set of error types accounts for the bulk of the failures, and they’re not obscure.
Five categories dominate. Low contrast text appears on 86.2% of homepages. Missing alt text on 54.5%. Empty links on 50.1%. Missing form labels on 45.5%. Keyboard navigation problems — missing focus indicators, unreachable controls, broken tab order — round out the top five.
None of these require deep WCAG fluency to fix. All of them are exactly what automated scanners flag — which means they’re exactly what plaintiff firms find when they’re prospecting for cases. The discovery process is industrialized: a scanner finds a violation, a demand letter goes out, settlement negotiations start before you’ve even pulled up your codebase.
The pragmatic move is to stop trying to audit against the full 78 success criteria on day one. Fix the five things that show up in the majority of complaints, then iterate. This is also where the overlay-widget pitch falls apart. accessiBe, UserWay, and the rest sit on top of broken markup — they don’t fix any of the five failure modes above, and courts have stopped accepting them as a defense.
Five fixes. Each one is a code pattern you can ship this sprint.
The 5 Fixes That Cover 80% of Lawsuits
Fix #1: Color Contrast (86.2% of sites)
WCAG requires 4.5:1 contrast for body text against its background, 3:1 for large text (18pt+, or 14pt bold). Open DevTools, inspect any text element, and the color picker shows the computed ratio with a pass/fail badge. That’s the entire workflow.
The traps are predictable. Light-gray placeholder text inside form inputs usually fails. Disabled button states often fail and frequently get a pass because “they’re disabled” — they still need to be perceivable. Overlay text on hero images fails when the image is light and there’s no scrim. Brand-mandated “soft” gray body text at #999 on white is 2.85:1 and a guaranteed scanner hit.
Fix it in tokens, not one-off overrides. Set a minimum-contrast pair in your design system and use it everywhere body text appears. One CSS token change can clear thousands of violations.
Fix #2: Image Alt Text (54.5% of sites)
The decision tree is shorter than most tutorials suggest. Informative image → describe what it conveys (alt="Quarterly revenue chart showing 23% growth"). Decorative image → empty alt (alt="") so screen readers skip it; never omit the attribute. Functional image, like an icon-only button → describe the action, not the picture (alt="Close menu", not alt="X icon"). Complex image — chart, diagram — short alt plus a longer description in adjacent text or via aria-describedby.
<!-- Decorative -->
<img src="divider.svg" alt="">
<!-- Functional -->
<button><img src="trash.svg" alt="Delete item"></button>
<!-- Informative -->
<img src="chart.png" alt="Q1 revenue grew 23% to $4.2M">
The most common mistake isn’t a wrong alt — it’s a missing one. Set a lint rule. CI catches it before the PR ships.
Fix #3: Empty Links and Buttons (50.1% of sites)
If a screen reader announces “link” with nothing after it, the user has no idea what it does. This is what scanners flag as “empty link” and it dominates icon-driven UIs.
The pattern: every interactive element needs an accessible name. Visible text counts. If there isn’t visible text, use aria-label for short labels or visually-hidden text for longer ones. Avoid title attributes — they don’t work on touch and screen reader support is inconsistent.
<!-- Broken: announces as "link" -->
<a href="/cart"><svg>...</svg></a>
<!-- Fixed: announces as "Shopping cart, 3 items" -->
<a href="/cart" aria-label="Shopping cart, 3 items">
<svg aria-hidden="true">...</svg>
</a>
While you’re in there, kill “click here” and “learn more” links. They fail in screen reader link-list mode, where users navigate by tabbing through link text out of context. Make the link text describe the destination.
Fix #4: Form Labels and Error Messages (45.5% of sites)
Every input needs a real <label> — either explicitly associated via for and id, or wrapping the input. Placeholders are not labels; they disappear on focus and fail contrast. aria-label works as a fallback when a visual label genuinely doesn’t fit, but a visible label is almost always the right answer.
For hints and errors, use aria-describedby to bind helper text to the input, and aria-invalid="true" plus a visible error message for validation failures.
<label for="email">Email address</label>
<input
id="email"
type="email"
aria-describedby="email-hint email-error"
aria-invalid="true"
/>
<p id="email-hint">We'll send your receipt here.</p>
<p id="email-error">Please enter a valid email address.</p>
If you’re shipping a form that gates revenue — checkout, signup, lead capture — this fix has the highest financial floor of any item in the list.
Fix #5: Keyboard Navigation and Focus
Unplug your mouse. Try to use your own site. The keyboard test surfaces more real issues in five minutes than most automated scans surface in an hour.
The 2-line baseline most sites are missing:
:focus-visible {
outline: 2px solid #4ade80;
outline-offset: 2px;
}
That alone fixes the visible-focus violation that lives on roughly every CSS reset that included outline: none without a replacement.
Then: every page needs a skip-to-content link as the first focusable element so keyboard users can bypass the nav. Never use positive tabindex values — they break the natural reading order. Modals must trap focus while open and restore focus to the trigger element when closed. Custom dropdowns and menus need keyboard handlers, not just click handlers.
Do these five and you’ve addressed the errors behind the bulk of accessibility lawsuits. The next question is which ones your specific site actually breaks.
The 60-Minute Audit Workflow
You don’t need a four-week engagement to find your high-risk violations. You need an hour and your three highest-traffic pages.
Minutes 0-15. Run axe DevTools or Lighthouse’s accessibility audit on each page. Note every violation. Ignore the “needs review” warnings on the first pass — those are useful, but they slow you down before you’ve cleared the certain failures.
Minutes 15-25. Run the WAVE browser extension on the same pages. It surfaces contrast and structural issues that axe sometimes misses, and the visual overlay is faster to scan than a JSON report.
Minutes 25-40. Unplug the mouse. Tab through each page top to bottom. Can you reach every interactive element? Is focus visible at every step? Can you escape a modal with Escape? Can you operate the menu? If anything traps focus or skips an element, you have a P0.
Minutes 40-55. One screen reader pass. macOS VoiceOver (Cmd+F5) or NVDA on Windows. You don’t need fluency — listen for “link” with no destination, “button” with no label, inputs with no associated label, and headings that don’t describe their section.
Minutes 55-60. Triage. Anything that breaks a core flow — checkout, signup, primary navigation — is P0 and ships this week. Everything else goes into the backlog tagged a11y for the next sprint.
What this misses: cognitive accessibility, motion sensitivity, full WCAG conformance, the long tail of low-frequency edge cases. This audit isn’t a substitute for that work. It’s the audit that catches the things you’re most likely to get sued for, and it fits inside a single coffee.
What to Ship This Sprint
Recap the loop: federal lawsuit filings are up 27%, 95.9% of homepages fail WCAG, and the April 2026 deadline extension doesn’t apply to private businesses or healthcare. The risk is real, it’s quantified, and it doesn’t wait for compliance theater.
Block 60 minutes Monday. Run the audit on your three highest-traffic pages. Ship Fix #1 (contrast tokens) and Fix #5 (:focus-visible plus a skip link) this week — they’re a handful of CSS lines and a templating tweak. Fixes 2, 3, and 4 take a pass through your image, link, and form components, no new dependencies, no vendor required.
Skip the overlay widgets. They don’t fix any of the five failure modes above, courts have stopped treating them as a defense, and the accessibility-as-purchase framing is the wrong mental model entirely. Accessibility isn’t a product. It’s markup discipline — closer to writing maintainable code than to buying a compliance tool.
Five fixes, one sprint, a real reduction in legal exposure — and a site that works for more of your users by accident. That’s the deal.