Web Accessibility Lawsuits Are Surging: A Developer's Guide to Not Getting Sued

Here is a number that should make every developer and business owner pay attention: over 4,000 federal lawsuits were filed in 2024 alleging that websites violate the Americans with Disabilities Act. That is not a typo. Four thousand. And the number has been climbing steadily year over year, with no sign of slowing down.

If your website is not accessible, you are not just excluding users with disabilities — you are exposing your business to real legal and financial risk. This is not hypothetical. Companies of every size, from Fortune 500 retailers to three-person SaaS startups, have received demand letters and faced lawsuits over inaccessible websites.

This guide is written for developers and technical founders who want to understand the legal landscape, identify the most common violations, and fix them before a plaintiff's attorney does it for you. Think of it as a practical, urgent playbook — not legal advice, but the kind of warning a friend who happens to be a lawyer would give you over coffee.

The Legal Landscape: Why This Matters Now

ADA Title III and Websites

The Americans with Disabilities Act was signed into law in 1990, long before the modern web existed. Title III prohibits discrimination in "places of public accommodation." Courts have increasingly interpreted this to include websites, especially for businesses that also have physical locations. The landmark Robles v. Domino's Pizza case in 2019 confirmed that websites and mobile apps must be accessible under the ADA.

There is no explicit ADA standard for websites. But courts and the Department of Justice have consistently pointed to WCAG 2.1 Level AA as the benchmark. If your site meets WCAG 2.1 AA, you have a strong defense. If it does not, you are vulnerable.

Section 508

If you build anything for the U.S. federal government — websites, internal tools, procurement platforms — Section 508 of the Rehabilitation Act requires WCAG 2.0 Level AA compliance. This is not optional. Government contracts can be revoked for non-compliance.

The European Accessibility Act (EAA)

Starting in June 2025, the European Accessibility Act requires that digital products and services sold in the EU meet accessibility standards. This covers e-commerce, banking, transport, and more. If you serve European customers, this applies to you regardless of where your company is based.

AODA (Canada)

Ontario's Accessibility for Ontarians with Disabilities Act requires organizations with 50 or more employees to make their websites WCAG 2.0 Level AA compliant. Other Canadian provinces are following suit.

The bottom line: web accessibility is a legal requirement in most major markets. The specific law varies, but the standard is almost always WCAG 2.1 AA.

Who Gets Sued and Why

If you think accessibility lawsuits only target big corporations, think again. The data tells a different story.

The Most Targeted Industries

• E-commerce and retail — By far the most targeted. If you sell anything online, you are in the highest-risk category. Roughly 75% of ADA web accessibility lawsuits target online stores.
• Food service and hospitality — Restaurants, hotels, and delivery platforms.
• Financial services — Banks, insurance companies, fintech apps.
• Healthcare — Patient portals, appointment scheduling, telehealth.
• SaaS and technology — Increasingly targeted, especially B2C platforms.
• Education — Universities and online learning platforms.

What Triggers a Lawsuit

There are three common triggers, and understanding them helps you assess your risk:

1. Serial plaintiffs and their attorneys. A significant portion of ADA web lawsuits are filed by a relatively small number of plaintiffs and law firms that specialize in accessibility litigation. They systematically scan websites for violations using automated tools, then file suit. This is legal, and courts have upheld their standing.

2. Competitor-driven lawsuits. In some cases, a competitor or disgruntled party will flag your site's accessibility issues to a plaintiff's firm. It is an ugly tactic, but it happens.

3. Actual users who cannot access your site. This is the most legitimate trigger and the one you should care about most. A visually impaired user tries to buy something on your site, cannot navigate it with a screen reader, and contacts an attorney. These cases are the hardest to defend against because the harm is real and documented.

The Cost of a Lawsuit

Most ADA web accessibility lawsuits settle for $5,000 to $50,000 in damages and legal fees, plus the cost of remediation. But the real cost is often higher when you factor in legal expenses, management time, and reputational damage. Some cases have settled for six figures.

The cost of preventing a lawsuit — running an accessibility audit and fixing the issues — is almost always a fraction of the cost of defending one.

The Top 10 Accessibility Violations That Trigger Lawsuits

These are the most common WCAG failures found in accessibility lawsuits, ordered roughly by frequency. Every one of these has appeared in real litigation.

1. Missing Alt Text on Images

What it is: Images without alt attributes, or with empty, unhelpful alt text like "image" or "photo."

Why it matters: Screen readers rely on alt text to describe images to visually impaired users. Without it, users hear nothing or "unlabeled image," which makes the page incomprehensible.

How to fix it:

<!-- Bad -->
<img src="product-shoe.jpg" />
<img src="banner.jpg" alt="image" />

<!-- Good -->
<img src="product-shoe.jpg" alt="Red running shoe, Nike Air Max, side view" />

<!-- Decorative images should use empty alt -->
<img src="decorative-border.png" alt="" />

Every meaningful image needs descriptive alt text. Decorative images should have alt="" so screen readers skip them entirely.

2. Poor Color Contrast

What it is: Text that does not have enough contrast against its background, making it hard or impossible to read for users with low vision or color blindness.

Why it matters: WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). Failing this is one of the most common violations found by automated scanners.

How to fix it:

/* Bad - contrast ratio ~2.5:1 */
.light-text {
  color: #999999;
  background-color: #ffffff;
}

/* Good - contrast ratio ~7:1 */
.accessible-text {
  color: #333333;
  background-color: #ffffff;
}

Use tools like the WebAIM Contrast Checker to verify your color combinations meet the minimum ratios.

3. No Keyboard Navigation

What it is: Interactive elements (buttons, links, menus, modals) that cannot be reached or activated using only the keyboard.

Why it matters: Many users with motor disabilities cannot use a mouse. They rely entirely on keyboard navigation (Tab, Enter, Escape, arrow keys). If your site cannot be navigated by keyboard alone, it is effectively broken for these users.

How to fix it:

/* Bad - div acting as button, not keyboard accessible */
<div onClick={handleClick} className="button">Submit</div>

/* Good - native button, keyboard accessible by default */
<button onClick={handleClick} className="button">Submit</button>

/* If you must use a div, add keyboard support */
<div
  role="button"
  tabIndex={0}
  onClick={handleClick}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      handleClick();
    }
  }}
>
  Submit
</div>

The simplest rule: use native HTML elements (button, a, input, select) whenever possible. They come with keyboard support built in.

4. Missing Form Labels

What it is: Form inputs without associated label elements, or with placeholder text used as a substitute for labels.

Why it matters: Screen readers announce the label when a user focuses on an input. Without a label, users hear "edit text" with no context about what to type. Placeholder text disappears when the user starts typing and is not reliably read by all screen readers.

How to fix it:

<!-- Bad - no label, placeholder only -->
<input type="email" placeholder="Enter your email" />

<!-- Good - explicit label association -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com" />

<!-- Also good - wrapping label -->
<label>
  Email address
  <input type="email" placeholder="you@example.com" />
</label>

<!-- If label must be visually hidden -->
<label for="search" className="sr-only">Search</label>
<input type="search" id="search" placeholder="Search..." />

5. No Skip Navigation Link

What it is: The absence of a "Skip to main content" link at the top of the page that lets keyboard users bypass repetitive navigation menus.

Why it matters: Without skip navigation, a keyboard user must Tab through every single navigation link on every page load before reaching the main content. On a site with a complex nav menu, this can mean dozens of tab presses.

How to fix it:

<!-- Add as the first focusable element in the body -->
<a href="#main-content" className="skip-link">
  Skip to main content
</a>

<!-- ... navigation here ... -->

<main id="main-content">
  <!-- Page content -->
</main>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

This is a quick win — it takes five minutes to implement and immediately improves the experience for keyboard users.

6. Auto-Playing Media Without Controls

What it is: Video or audio that plays automatically without a visible pause, stop, or mute button.

Why it matters: Auto-playing audio can be extremely disruptive for screen reader users because it interferes with their screen reader's speech output. Auto-playing video with flashing content can trigger seizures in users with photosensitive epilepsy.

How to fix it:

<!-- Bad -->
<video src="promo.mp4" autoplay></video>

<!-- Good - muted autoplay with controls visible -->
<video src="promo.mp4" autoplay muted controls>
  <track kind="captions" src="promo-captions.vtt" srclang="en" label="English" />
</video>

<!-- Best - no autoplay at all -->
<video src="promo.mp4" controls>
  <track kind="captions" src="promo-captions.vtt" srclang="en" label="English" />
</video>

If you must autoplay, mute it by default and always provide visible controls. Include captions for video content.

7. Missing Page Titles

What it is: Pages without a descriptive title element, or all pages sharing the same generic title.

Why it matters: The page title is the first thing a screen reader announces when a page loads. It is also what shows up in browser tabs and search results. A missing or generic title forces users to explore the entire page to understand where they are.

How to fix it:

<!-- Bad -->
<title>My App</title>  <!-- Same on every page -->

<!-- Good - descriptive and unique per page -->
<title>Shopping Cart (3 items) - My Store</title>
<title>Account Settings - My Store</title>
<title>Order #12345 Confirmation - My Store</title>

Every page should have a unique, descriptive title that conveys the page's purpose.

8. Inaccessible PDFs and Documents

What it is: PDF documents that are scanned images without text layers, or that lack proper heading structure, reading order, and alternative text.

Why it matters: Many organizations post essential documents (menus, policies, applications, invoices) as PDFs. If those PDFs are just scanned images, screen readers cannot read them at all. This has been the basis for numerous lawsuits, particularly against restaurants and government agencies.

How to fix it:

• Use tagged PDFs with proper heading structure and reading order
• Run PDFs through Adobe Acrobat's accessibility checker
• Provide an accessible HTML alternative alongside the PDF
• Never post scanned image PDFs without OCR and tagging

<!-- Provide HTML alternative -->
<p>
  <a href="/menu.pdf">Download menu (PDF)</a> |
  <a href="/menu">View accessible menu (HTML)</a>
</p>

9. CAPTCHA Without Alternatives

What it is: CAPTCHA challenges (especially image-based ones) that have no audio or alternative method for users who cannot see or interpret the images.

Why it matters: A visual CAPTCHA with no alternative is an absolute barrier. A blind user literally cannot pass it, which means they cannot create an account, submit a form, or complete a purchase. This is one of the clearest-cut accessibility violations.

How to fix it:

<!-- Use reCAPTCHA v3 (invisible, no user interaction) -->
<script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>

<!-- Or use reCAPTCHA v2 with audio alternative (built-in) -->
<div className="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>

<!-- Or use hCaptcha with accessibility cookie -->
<!-- hCaptcha provides an accessibility option at accounts.hcaptcha.com/accessibility -->

The best approach is to use invisible CAPTCHA (reCAPTCHA v3) or server-side bot detection that requires no user interaction at all. If you must use a visible CAPTCHA, ensure it has an audio alternative.

10. Dynamic Content Not Announced to Screen Readers

What it is: Content that updates dynamically (notifications, form validation errors, live search results, chat messages) without informing assistive technology that something changed.

Why it matters: Screen readers do not automatically detect DOM changes. If a form validation error appears visually but is not announced, a screen reader user does not know why their form submission failed. This is increasingly common in modern single-page applications.

How to fix it:

<!-- Use ARIA live regions to announce dynamic content -->
<div role="alert" aria-live="assertive">
  <!-- Error messages inserted here will be announced immediately -->
</div>

<div aria-live="polite">
  <!-- Status updates inserted here will be announced at the next pause -->
</div>

<!-- Example: form validation -->
<label for="email">Email</label>
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
/>
<span id="email-error" role="alert">
  Please enter a valid email address.
</span>

Use aria-live="assertive" for urgent updates (errors, alerts) and aria-live="polite" for informational updates (search results, status changes).

Automated Accessibility Testing Tools

Manual testing is essential, but automated tools can catch a huge percentage of common violations quickly. Here are the tools every developer should know about.

axe-core

The industry standard accessibility testing engine, created by Deque Systems. It powers most other accessibility tools under the hood. You can integrate it directly into your test suite.

// Using @axe-core/playwright in your test suite
import AxeBuilder from '@axe-core/playwright';

test('homepage should have no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Lighthouse

Built into Chrome DevTools, Lighthouse includes an accessibility audit based on axe-core. Run it from the Audits tab or via CLI. Good for quick checks, but limited in scope compared to dedicated tools.

# Run Lighthouse accessibility audit from CLI
npx lighthouse https://yoursite.com --only-categories=accessibility --output=json

WAVE

The Web Accessibility Evaluation Tool from WebAIM. Available as a browser extension and API. It provides a visual overlay showing exactly where accessibility issues occur on the page. Excellent for quick visual audits.

Pa11y

An open-source command-line accessibility testing tool. Great for CI/CD integration and batch testing multiple pages.

# Test a single page
npx pa11y https://yoursite.com

# Test multiple pages with a config file
npx pa11y-ci --config pa11y-ci.json

Plaintest

Plaintest takes a different approach to accessibility testing. Instead of scanning a single page, it uses AI to autonomously explore your entire application — clicking through pages, navigating flows, and interacting with elements the way a real user would. During this exploration, it runs automated WCAG audits on every screen it discovers.

This means you get accessibility coverage across your entire app, not just the pages you remember to test. It catches violations in authenticated flows, multi-step forms, and dynamically loaded content that static scanners often miss. The results map directly to WCAG success criteria, so you know exactly what standard each violation relates to and how to prioritize the fix.

The Limits of Automation

Automated tools typically catch 30-50% of WCAG violations. They are excellent at finding missing alt text, contrast issues, missing labels, and ARIA misuse. But they cannot catch everything. Issues like logical reading order, meaningful link text, and whether alt text is actually descriptive require human judgment.

The essential strategy is to use automated tools as your first line of defense, then supplement with manual testing using a keyboard and screen reader.

Remediation Priority Checklist

If you are staring at a long list of accessibility violations and do not know where to start, use this priority order. It is organized by a combination of legal risk, user impact, and ease of fix.

Priority 1 — Fix immediately (high legal risk, usually easy to fix):

• [ ] Add alt text to all meaningful images
• [ ] Associate all form inputs with labels
• [ ] Add a skip navigation link
• [ ] Ensure all pages have unique, descriptive titles
• [ ] Fix color contrast failures (4.5:1 minimum for text)

Priority 2 — Fix this week (high impact, moderate effort):

• [ ] Ensure all interactive elements are keyboard accessible
• [ ] Add ARIA live regions for dynamic content and error messages
• [ ] Provide audio alternative for any CAPTCHA
• [ ] Remove or mute auto-playing media, add visible controls
• [ ] Add visible focus indicators for keyboard navigation

Priority 3 — Fix this month (important, potentially higher effort):

• [ ] Audit and remediate all PDF documents (or provide HTML alternatives)
• [ ] Test all forms and flows with a screen reader (NVDA on Windows, VoiceOver on Mac)
• [ ] Review heading hierarchy (one h1 per page, logical nesting)
• [ ] Ensure all modals and dropdowns trap focus correctly
• [ ] Add language attribute to the HTML element

Priority 4 — Ongoing (build into your process):

• [ ] Add accessibility checks to your CI/CD pipeline
• [ ] Run automated audits with tools like axe-core or Plaintest on every deployment
• [ ] Include accessibility acceptance criteria in user stories
• [ ] Train your team on basic accessibility principles
• [ ] Test with real assistive technology at least quarterly

What to Do If You Receive a Demand Letter

If a demand letter or lawsuit lands on your desk, here is what to do:

Do not panic. Most ADA web accessibility cases settle. Very few go to trial. The plaintiff's attorneys usually want a settlement and a commitment to remediate, not a prolonged court battle.

Do not ignore it. Ignoring a demand letter does not make it go away. It makes it worse. Courts view failure to respond as evidence of indifference to accessibility.

Assess the claims. Run an automated accessibility audit immediately. Determine which of the alleged violations are real. Document your current state and any accessibility efforts you have already made.

Start remediating immediately. Courts look favorably on defendants who demonstrate good faith efforts to fix accessibility issues. Begin with the Priority 1 items from the checklist above. Document everything you fix and when you fixed it.

Consult an attorney experienced in ADA web accessibility. Not all attorneys understand this area of law. Find one who does. Organizations like the International Association of Accessibility Professionals (IAAP) can provide referrals.

Consider publishing an accessibility statement. An accessibility statement on your website that acknowledges your commitment to accessibility, identifies known issues, and provides a contact method for reporting barriers demonstrates good faith.

<!-- Example accessibility statement page -->
<!-- Place a link in your footer: /accessibility -->

Develop a remediation plan with a timeline. Courts and plaintiffs' attorneys are often willing to settle if you present a concrete, time-bound plan to achieve WCAG 2.1 AA compliance. A 6-12 month remediation timeline with milestones is typical.

Building Accessibility Into Your Development Process

The cheapest and most effective way to handle web accessibility legal requirements is to never let violations accumulate in the first place. Here is how to make accessibility a default part of your workflow rather than a fire drill.

Use semantic HTML. This single practice prevents a large percentage of accessibility issues. Native HTML elements like button, a, nav, main, header, footer, label, and input have built-in accessibility features. The more you use them instead of styled div elements, the fewer accessibility bugs you will create.

Test with your keyboard. Once a week, put your mouse aside and try to use your own application with only the keyboard. Can you reach every interactive element? Can you see where your focus is? Can you operate menus and modals? This five-minute exercise catches issues no automated tool will find.

Automate what you can. Add axe-core to your test suite. Run Lighthouse in CI. Use Plaintest to get automated WCAG coverage across your entire application during AI-driven exploration. The goal is to catch regressions before they reach production.

Write an accessibility statement. Even a simple one shows good faith and gives users a way to report issues directly to you instead of to a lawyer.

The Bottom Line

Web accessibility lawsuits are not a future risk — they are a present reality. Over 4,000 federal lawsuits in 2024, thousands more demand letters, and an expanding set of international laws mean that ADA website compliance is no longer optional for any business with a web presence.

The good news is that the most common violations are also the most fixable. Missing alt text, poor contrast, missing labels, and keyboard navigation issues can be addressed in days, not months. And the tools available today — from axe-core to comprehensive platforms like Plaintest — make it easier than ever to find and fix these issues before they become legal problems.

Do not wait for a demand letter to take accessibility seriously. Audit your site this week. Fix the critical issues. Build accessibility into your process. Protect your business and, more importantly, make your product usable for everyone.

Your users with disabilities are not edge cases. They are 15-20% of the population. They are your customers, your colleagues, and your neighbors. Building an accessible web is not just a legal obligation — it is the right thing to do. And now, it is also an urgent one.