8 Web Accessibility Lawsuits and What You Can Learn From Them to Protect Your Site

8 Web Accessibility Lawsuits and What You Can Learn From Them to Protect Your Site

Web accessibility lawsuits are increasing in number. Learn what they are, why ADA risk is growing, 2025 case examples, and how to reduce exposure with WCAG 2.1 AA.

Will Sigsworth
Will Sigsworth
•
How-To Guides
•
Last updated: Feb 02, 2026
8 Web Accessibility Lawsuits and What You Can Learn From Them to Protect Your Site
Contents

    Maintaining a website that complies with accessibility regulations is vital if you want to avoid the risk of litigation and give all your visitors a good experience – especially as web accessibility lawsuits feel like they’re suddenly everywhere. In 2025 alone, there were more than 5,000 ADA-related digital accessibility lawsuits in the United States across federal and key state courts – a high volume, and still growing.

    The risk associated with ADA compliance is especially important if you’re part of a WebOps or Digital Excellence team juggling multiple brands, markets, and sites, as accessibility debt scales fast. One site quickly becomes 50 templates, 12 checkouts, and 3 CMS instances.

    Here are seven examples of If it feels like web accessibility lawsuits and what you can learn from them to reduce your own risk and improve your site’s compliance.

    TL;DR

    • Web accessibility lawsuits are usually ADA Title III claims alleging your website blocks equal access for people using assistive technology (like screen readers or keyboard navigation) and why you should fix “money” pages first.
    • 2025 stayed hot: There were over 5,000 federal cases, with eCommerce the biggest target.
    • Accessibility widgets and overlays don’t meaningfully reduce risk and may interfere with assistive tech.
    • The safest play is boring, but effective: aim for WCAG 2.1 Level AA, run real testing, fix issues at the code level, and make accessibility part of your release process. Our ADA compliance checklist can help.

    What are web accessibility lawsuits?

    That 5,000+ lawsuits total sounds abstract until you see what these cases actually claim: that a business’s website content or digital platforms are unusable for people with disabilities.

    Most website accessibility lawsuits follow a familiar pattern:

    1. A plaintiff (often someone with vision impairments) tries to use a site with screen readers or keyboard-only navigation.
    2. They hit barriers – missing alt text, broken keyboard navigation, poor color contrast, inaccessible forms, broken checkout processes, inaccessible video content, etc.
    3. A complaint is filed, often in federal court or a United States District Court, alleging violations of the Americans with Disabilities Act (ADA), usually ADA Title III (public accommodation), sometimes paired with state laws.

    The ADA doesn’t spell out “do X, Y, Z on your website,” so lawsuits often use the Web Content Accessibility Guidelines as the practical yardstick – most commonly WCAG 2.1 Level AA.

    These claims can arrive as demand letters or jump straight to lawsuits filed. Either way, they create real legal risks: legal fees, settlement costs, remediation deadlines, and (sometimes) reputational fallout.

    And that naturally leads to the question behind most web accessibility lawsuits news: why is this happening more now, and what does ADA compliance actually mean for websites?

    ADA compliance and why there are more web accessibility lawsuits in the news

    Now that we’ve defined what these lawsuits are, the “why now” comes down to a mix of legal ambiguity, higher enforcement pressure, and simple economics (popular, revenue-generating sites are worth suing).

    ADA basics (the part that matters for websites)

    • ADA Title III covers “places of public accommodation” including retail, restaurants, hotels, and services. Modern websites and apps are part of how those services are delivered – even when the law predates today’s internet.
    • Title II covers state and local governments and their digital services – important if you work with local governments or public-sector digital platforms. A few years ago, the DOJ finalized an ADA Title II rule requiring WCAG-based accessibility for government web/mobile content (commonly referenced as WCAG 2.1 AA).

    What 2025 data shows

    Recent reports on the number of accessibility lawsuits highlights just how systematic this has become:

    • There were 2,014 lawsuits filed in the first six months of 2025, up 37% year-over-year.
    • 3,195 federal ADA digital accessibility cases (62%) and 1,919 state-court (NY + CA) cases (38%).
    • New York and Florida drove much of the volume – companies don’t need to be headquartered in New York to face litigation there.
    • eCommerce (70%) is the #1 target, followed by food service (21%).
    • Bigger brands are increasingly targeted: in 2025, 36% of sued companies reported >$25M revenue, and 36% of the top 500 eCommerce retailers received at least one lawsuit.

    Just installing a widget is not a strategy

    2025 data suggests that the idea of adding an overlay and calling it ADA compliant isn’t going to work:

    • Lawsuits against companies using widgets stayed high, and warns these tools often don’t solve underlying code level remediation needs and may interfere with assistive technologies like screen readers.
    • On top of that, the FTC has targeted marketing claims around automated accessibility tools – another reminder that “ADA compliant” is a risky claim if you can’t prove meaningful accessibility compliance.

    So what does all of this look like in real court filings and outcomes? Let’s walk through 8 examples from 2025 – and the practical lessons hiding inside them.

    8 examples of web accessibility lawsuits and what you can learn from them

    The cases below aren’t just “gotcha” stories. They show patterns – where plaintiffs file, what defenses work (sometimes), and what courts order when a defendant doesn’t engage.

    1. Alcazar v. Fashion Nova, Inc. (N.D. Cal.)  –  class action settlement

    What happened: A legally blind plaintiff alleged Fashion Nova’s online store wasn’t accessible using screen-reading software, limiting equal access to shopping and vital content.

    How it ended (so far): A proposed class action settlement of $5.15 million with a claim period covering attempted access using screen readers from February 26, 2018 to present, with deadlines and a scheduled final approval hearing (per the settlement site).

    What you can learn:

    • Long-running accessibility litigation can get expensive fast – especially when it becomes a class action.
    • If you run online stores, your checkout processes and product browsing aren’t nice-to-have accessibility areas; they’re the lawsuit bullseye.

    More information can be found on a dedicated website.

    2. Wills v. Resorts World Las Vegas, LLC (E.D.N.Y.)  –  dismissed on personal jurisdiction

    What happened: A visually impaired plaintiff alleged he couldn’t book a hotel room because the site wasn’t compatible with screen access programs.

    How it ended: The court granted the motion to dismiss for lack of personal jurisdiction and didn’t reach standing.

    What you can learn:

    • Jurisdiction fights can win cases, but they don’t make websites more accessible or prevent litigation later on.
    • If your site targets website visitors nationally, or you run campaigns into certain states, assume you can be sued where you do business.

    More information can be found on the Justia website.

    3. Sumlin v. New York Beer Co., LLC (S.D.N.Y.)  –  default judgment and ordered remediation

    What happened: A legally blind plaintiff alleged the site needed proper HTML support, like alternative text, for screen readers.

    How it ended: The court granted default judgment and ordered the defendant to resolve accessibility issues identified in the plaintiff’s expert report “as soon as reasonably practicable,” with fees potentially awarded.

    What you can learn:

    • Ignoring a complaint is one of the fastest ways to turn potential lawsuits into an injunction and a forced remediation timeline.
    • “We’ll get to it later” is not a defense when a district court is issuing orders.

    More information can be found on the Justia website.

    4. Martin v. Brooklyn Bagel & Coffee Company, LTD. (E.D.N.Y.)  –  dismissed with prejudice on standing

    What happened: A legally blind plaintiff alleged barriers using screen-reading software on a restaurant’s site.

    How it ended: The case was dismissed with prejudice for lack of standing.

    What you can learn:

    • Standing (and “intent to return”) matters in federal court, and some defendants win on it.
    • But relying on standing arguments is like relying on your smoke alarm instead of building fire prevention. The risk returns – especially if your site stays inaccessible.

    More information can be found on the Justia website.

    5. Herrera v. Retrofitness, LLC (D.N.J.)  –  dismissed for lack of alleged intent to use services

    What happened: The complaint alleged website accessibility barriers tied to a gym business.

    How it ended: The court granted the motion to dismiss, where the plaintiff didn’t allege intent to visit a location or use services beyond browsing.

    What you can learn:

    • Courts scrutinize whether the plaintiff plausibly planned to use the goods/services.
    • Still, the “win” here is procedural. If your digital products keep failing basic accessibility compliance, you’re inviting the next filer with better allegations.

    Find out more on Converge Accessibility’s website.

    6. Fernandez v. Gainful Health, Inc. (S.D.N.Y.)  –  ADA claims dismissed with prejudice

    What happened: The plaintiff alleged the website wasn’t accessible for screen-reading technology.

    How it ended: The court granted the motion to dismiss the federal claims, dismissing them with prejudice, and declined supplemental jurisdiction over state-law claims.

    What you can learn:

    • Website accessibility lawsuits can rise or fall on how a court interprets “public accommodation” in the ADA wording, especially for online-only brands.
    • That split is exactly why waiting for the law to settle is risky – because you don’t control which judge (or which state court) you draw.

    Find out more in the official documentation of the case.

    7. Herrera v. Grove Bay Hospitality Group, LLC (S.D. Fla.)  –  vendor blame didn’t stick

    What happened: A Miami restaurant was sued under ADA Title III, then tried to bring its web developer/vendor, Popmenu, into the case, alleging the vendor assured WCAG conformance.

    How it ended: The court granted the vendor’s motion to dismiss, and the third-party complaint was dismissed with prejudice; the order notes contract terms stating the vendor did not warrant ADA compliance.

    What you can learn:

    • You can outsource development. You can’t outsource accountability.
    • Contracts often disclaim accessibility warranties – so if you want protection, you need explicit accessibility requirements, testing obligations, and remediation SLAs – and you still need internal ownership.

    Find out more in the official documentation of the case.

    8. National Federation of the Blind (NFB), et al. v. Target Corporation – case settled

    What happened: The president of the California Association of Blind Students took Target to court because the company’s website was inaccessible to blind people. Then, the National Federation of the Blind (NFB) joined on the side of the plaintiff.

    How it ended: Target reached a settlement with the NFB to pay $6,000,000 into a damages fund, as well as $3.7m in legal fees – and, importantly, to address accessibility issues on their website.

    What you can learn:

    • The case was originally brought to court by someone who really wanted to raise awareness – these aren’t nuisance claims, they’re from people who deserve equal treatment
    • The student took legal action in 2006, illustrating that even though laws have changed recently, accessibility has always been important

    Here are the official documents for more information.

    Key takeaways across these cases

    • Courts care about standing, jurisdiction, and pleadings – but plaintiffs and plaintiff firms adapt.
    • eCommerce and high-traffic sites are targeted because plaintiffs can plausibly say they’d return.
    • The cheapest time to fix accessibility violations is before they become demand letters.

    Which brings us to the part you can actually control: building an accessibility program that survives new pages, new campaigns, and new releases.

    How to avoid a website accessibility lawsuit

    After seeing how these lawsuits play out, the avoidance strategy becomes clearer: don’t chase one-off fixes, build a repeatable accessibility compliance workflow – like you would for security or performance.

    Bear in mind that this is practical guidance, not legal advice. For specific legal exposure, talk to counsel.

    1. Pick your target: WCAG 2.1 Level AA

    Most teams aim for WCAG 2.1 Level AA because it’s the most commonly referenced baseline in accessibility programs and compliance checklists.

    Document it internally as your standard, along with:

    • Which digital platforms are in scope – marketing site, app, logged-in areas, checkout, PDFs, and video content
    • Which teams own what – design system, content, frontend, and QA

    2. Audit like you mean it

    Automated scanners are useful – but they don’t tell you if a checkout flow is usable with a keyboard, or whether a modal traps focus.

    A strong audit mix looks like:

    • Automated checks for obvious issues, like missing labels, alt text, and headings
    • Manual keyboard navigation through critical flows
    • Screen reader spot checks on templates and key pages
    • User testing with people who rely on assistive technology, if possible

    Our ADA compliance checklist and accessibility issues guide are solid references for what to look for and what “good” looks like in practice.

    3. Fix the money pages first, because that’s where suits land

    If you run online stores, prioritize:

    • Category and product pages
    • Search and filters
    • Cart and checkout processes
    • Account creation and login
    • Error states, like validation messaging and focus placement

    This aligns with what the lawsuits in 2025 were often targeting, as e-commerce accessibility lawsuits represents 70% of tracked cases.

    4. Do code-level remediation (and don’t rely on overlays)

    You’ll see lots of pitches for one-line accessibility, but the consistent lesson is that overlays don’t replace fixing the underlying UI.

    Lawsuits remained high against companies using widgets last year. Widgets may not resolve code-level issues and can interfere with assistive technologies like screen readers.

    In practice, code-level remediation often means:

    • Semantic HTML – Proper buttons/labels, headings, and landmarks
    • Accessible forms – Labels, instructions, and error handling
    • Correct focus management – Especially for modals and menus
    • Meaningful alt text
    • Captions and transcripts for video content
    • Meeting contrast requirements – e.g., avoid poor color contrast
    • Ensuring all vital content is reachable without a mouse

    5. Make accessibility part of your release process (not a quarterly panic)

    This is where “being accessible” becomes sustainable:

    • Add accessibility checks to your definition of done
    • Use a website QA checklist that includes accessibility regression items, such as navigation, forms, media, and responsive states
    • Build and enforce an accessible component library/design system
    • Train content teams, because a surprising number of accessibility violations are content-driven

    If you want this to work across many teams and sites, treat accessibility like a product quality program – owned, measured, and continuously improved.

    6. Be careful with “ADA-compliant” marketing claims

    There are two reasons you should be wary of making claims about your ADA compliance:

    1. Accessibility is not binary; it’s a spectrum of user experience quality across devices, content types, and assistive tech.
    2. Regulators have scrutinized overstated claims tied to automated accessibility products.

    A safer approach is to publish an accessibility statement, explain your standard (WCAG 2.1 AA) – what’s in scope and how users can report issues – and maintain logs of audits, fixes, and improvements, which are helpful for compliance lawsuits and internal accountability.

    7. Operationalize issue intake so nothing slips

    Accessibility work dies when issues are not reproducible or missing context.

    Borrow from what already works in QA and user acceptance testing:

    • Use a bug report template so accessibility bugs include steps, expected behavior, actual behavior, environment, and screenshots or screen recordings.
    • Run bug triage weekly so issues get prioritized and assigned like real work.
    • Keep a test plan template so audits and regressions don’t depend on tribal knowledge.
    • Include accessibility reviews in any website QA testing needs to be done.

    8. If you get a demand letter or complaint, don’t freeze

    This is where many teams get burned. Regardless of the legal strategy:

    • Loop in counsel early
    • Start remediation immediately (courts and plaintiffs look for substantive fixes)
    • Capture evidence of what you changed and when
    • Avoid quick cosmetic patches that leave structural issues behind – plaintiff firms monitor prior defendants and repeat targeting is common

    Final thoughts

    Web accessibility lawsuits aren’t a niche legal headache any more, they’re a predictable risk for any business with a public-facing website, especially e-commerce and high-traffic brands. The good news is that you don’t need perfection to lower your exposure. You need a real accessibility process.

    Start with the basics, then make it repeatable:

    • Pick a standard, like WCAG 2.1 Level AA, and define what “done” means for your team.
    • Audit your highest-value flows first – navigation, CTA buttons, forms, and checkout.
    • Fix issues at the code level, not via accessibility widgets or overlays.
    • Bake accessibility checks into every release, so you’re not relearning the same lessons every quarter.
    • Create a clear way for users and teammates to report accessibility problems, such as a tool like marker.io, and make sure reports include the URL, steps to reproduce, and screenshots and screen recordings so fixes don’t stall in back-and-forth.

    If you treat accessibility like QA, ensuring it’s ongoing, measurable, owned, and reported, you’ll serve more users, reduce legal risks, and spend less time reacting to demand letters and accessibility litigation.

    What should I do now?

    Here are three ways you can continue your journey towards delivering bug-free websites:

    2.

    Read Next-Gen QA: How Companies Can Save Up To $125,000 A Year by adopting better bug reporting and resolution practices (no e-mail required).

    3.

    Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things QA testing, software development, bug resolution, and more.

    Will Sigsworth

    Will Sigsworth

    Will manages organic content at Marker.io. He also works as a marketing advisor and contributor to a number of other SaaS businesses.

    Frequently Asked Questions

    What is Marker.io?

    Marker.io is a website feedback and annotation tool for websites. It’s the best way to gather feedback and bug reports with screenshots, annotations & advanced technical meta-data. It also integrates perfectly with Jira, Trello, ClickUp, Asana (and more).

    Who is Marker.io for?

    Marker.io is for teams responsible for shipping and maintaining websites who need a simple way to collect visual feedback and turn it into actionable tasks.
    ‍
    It’s used by:
    ‍
    - Organizations managing complex or multi-site websites
    - Agencies collaborating with clients
    - Product, web, and QA teams inside companies

    ‍
    Whether you’re building, testing, or running a live site, Marker.io helps teams collect feedback without slowing people down or breaking existing workflows.

    How easy is it to set up?

    Embed a few lines of code on your website and start collecting client feedback with screenshots, annotations & advanced technical meta-data! We also have a no-code WordPress plugin and a browser extension.

    Will Marker.io slow down my website?

    No, it won't.

    The Marker.io script is engineered to run entirely in the background and should never cause your site to perform slowly.

    Do clients need an account to send feedback?

    No, anyone can submit feedback and send comments without an account.

    How much does it cost?

    Plans start as low as $39 per month. Each plan comes with a 15-day free trial. For more information, check out the pricing page.

    Get started now

    Free 15-day trial  •  No credit card required •  Cancel anytime