In 2025, plaintiffs filed 3,117 website accessibility lawsuits under ADA Title III in federal court — a 27 percent jump over 2024 and the highest annual figure since 2022. Add in state court filings and the total tops 5,000. Even that headline number understates the pressure: defense attorneys estimate that 35,000 to 50,000 accessibility demand letters were sent to U.S. businesses last year, most of which settle privately for between $1,000 and $25,000 without ever appearing in a docket.
If your business operates a website, a mobile app, an online store, a booking widget, or a customer portal, you are now a realistic target. And serial plaintiffs are no longer limited to a small cluster of repeat filers — roughly 40 percent of 2025 federal ADA Title III filings came from self-represented individuals, many of whom use AI-powered scanners to identify potential defendants and draft complaints in minutes.
This guide walks through what ADA Title III actually requires for digital experiences, why WCAG 2.1 Level AA has become the de facto benchmark, what a remediation roadmap looks like, and how to build a defensible record before a demand letter arrives.
Why Your Website Is Now in Scope for ADA Title III
Title III of the Americans with Disabilities Act prohibits discrimination on the basis of disability in places of public accommodation. The statute was written in 1990 and never explicitly mentioned websites or mobile apps — but courts have spent the last decade resolving that ambiguity, almost always in favor of plaintiffs.
The Robles v. Domino's Pizza Legacy
The single most important case is Robles v. Domino's Pizza. Guillermo Robles, a blind plaintiff in California, sued Domino's in 2016 after discovering that he could not use the pizza chain's website or mobile app with a screen reader. The district court initially dismissed the case on due process grounds, reasoning that without published web accessibility regulations, Domino's had no fair notice of what compliance required.
The Ninth Circuit reversed that decision in 2019. The court held that Title III covered Domino's website and app because they had a nexus to a physical place of public accommodation (the pizza restaurants), and that imposing liability did not violate due process even without published technical standards. The Supreme Court declined to review the Ninth Circuit decision later that year, leaving the rule in place. Domino's eventually settled in June 2022 after six years of litigation.
The practical effect is that any business with a physical location — and, in many circuits, even purely online businesses — now faces real exposure for an inaccessible website.
The DOJ's 2024 Title II Rule and Its Title III Spillover
In April 2024, the Department of Justice issued a final rule under Title II of the ADA requiring state and local government websites and mobile apps to conform with WCAG 2.1 Level AA. Although that rule formally binds only public entities, plaintiffs and courts immediately began citing it as the most authoritative federal articulation of what "accessible" means.
For a private business, the legal calculus changed overnight. Even if Title III still has no published technical standard, a plaintiff can now point to a binding federal regulation that names WCAG 2.1 Level AA as the standard for materially similar Title II entities. Most defense lawyers now advise their Title III clients to treat WCAG 2.1 Level AA as the floor.
What WCAG 2.1 Level AA Actually Requires
WCAG — Web Content Accessibility Guidelines, maintained by the World Wide Web Consortium — is organized around four principles, conveniently summarized by the acronym POUR: Perceivable, Operable, Understandable, and Robust. Level AA includes every Level A success criterion plus additional AA-specific criteria. There are 50 success criteria total at Level AA, but a handful drive the overwhelming majority of demand letters.
Color Contrast (1.4.3 and 1.4.11)
Body text must have a contrast ratio of at least 4.5:1 against its background. Large text (18 point or 14 point bold) needs at least 3:1. Buttons, form field borders, focus indicators, and other interactive graphical elements must meet 3:1 against adjacent colors. A lot of demand letters originate here because automated scanners detect contrast failures in seconds.
Text Alternatives for Non-Text Content (1.1.1)
Every image, icon, chart, photo, and graphic that carries meaning needs an alt attribute that conveys the same information. Decorative images get an empty alt attribute (alt="") so screen readers skip them. Logos should describe the brand. Charts and infographics need a longer text equivalent nearby or linked. Form input icons need labels. CAPTCHAs need an audio alternative.
Keyboard Operability (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Every interactive element — menus, modals, carousels, accordions, tabs, custom dropdowns — must be reachable and operable using only the keyboard. Users must never get trapped inside a widget with no way out (the classic "modal that won't close without a mouse" failure). Focus order must be logical and a visible focus indicator must always show where the user is on the page.
Form Labels, Errors, and Instructions (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Every form input needs a programmatically associated label (a <label for=""> element or aria-label). Error messages must identify which field failed and what to do about it. For high-stakes forms (checkout, account creation, legal acknowledgments), users need a chance to review and correct before submission.
Captions and Audio Descriptions (1.2.2, 1.2.5)
Pre-recorded video needs synchronized captions. If essential information is conveyed visually and not in the audio track, you also need audio descriptions. Live video at Level AA needs live captions.
Heading Structure and Landmarks (1.3.1, 2.4.6)
Headings must follow a logical hierarchy (h1 → h2 → h3, not skipping levels arbitrarily). Use semantic HTML elements — <nav>, <main>, <header>, <footer> — or ARIA landmarks so screen reader users can jump to the section they want. Avoid styling a <div> to look like a heading without giving it the right semantic role.
Resize and Reflow (1.4.4, 1.4.10)
Text must remain readable at 200 percent zoom without horizontal scrolling. Layouts must reflow on a 320 CSS pixel viewport without two-dimensional scrolling.
Where the Lawsuits Are Concentrated
Three federal districts account for the bulk of website accessibility filings: the Southern District of New York, the Central District of California, and the Southern District of Florida. New York leads by a wide margin, in part because the New York State Human Rights Law and New York City Human Rights Law provide additional state-law hooks and lower pleading bars than federal ADA claims.
California adds the Unruh Civil Rights Act, which provides $4,000 in statutory damages per violation per plaintiff. That changes the settlement math dramatically — a small claim can quickly become a six-figure exposure if a class action gets certified.
Florida has emerged as the third hub since 2020, with a handful of plaintiff firms developing high-volume practices targeting restaurant chains, hospitality brands, and direct-to-consumer e-commerce shops.
Building a Remediation Roadmap
If you receive a demand letter — or, better, if you act before one arrives — the work breaks down into roughly five phases. Treat this as a project with a budget and a deadline, not a one-time audit.
Phase 1: Automated and Manual Audit
Start with an automated scan using a tool like axe DevTools, WAVE, or Google Lighthouse. Automated tools catch somewhere between 30 and 50 percent of WCAG failures — the rest require manual testing with a screen reader (NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android), keyboard-only navigation, and zoom and reflow testing.
Document each failure with the WCAG criterion violated, the page or template affected, the severity, and an estimated remediation effort. This audit log becomes the spine of every later phase.
Phase 2: Design System and Component Fixes
Most of the highest-volume failures live in your design system: button contrast, focus indicators, form inputs, modal patterns, carousel controls, navigation menus. Fixing the component once fixes every instance of it. Prioritize the components that appear on the most pages.
Phase 3: Content Sweep
Alt text, video captions, heading structure, and form labels are usually content-level fixes that touch the most templates and pages. Build a content checklist that authors must follow for every new page and a backlog item for retroactively fixing existing pages.
Phase 4: Third-Party Vendor Coordination
Most modern websites embed third-party widgets: payment forms, live chat, booking calendars, video players, analytics overlays, review widgets, and email capture pop-ups. Every one of these can introduce its own accessibility failures, and Title III courts have generally held that a business is responsible for the accessibility of vendor code it embeds on its own site.
For each vendor, request a current VPAT (Voluntary Product Accessibility Template) or Accessibility Conformance Report. Verify that the version they ship meets WCAG 2.1 Level AA. Push vendors that fall short to remediate, or swap them out.
Phase 5: Accessibility Statement and Feedback Channel
Publish a clearly linked accessibility statement that names the standard you aim to meet (typically WCAG 2.1 Level AA), the known limitations, and a contact channel (email and phone) for users to report accessibility issues. The statement does not provide legal immunity, but it documents good faith and gives demand-letter responders something concrete to point to.
A Word About Accessibility Overlays
A booming industry of "accessibility overlay" tools — JavaScript widgets that promise instant WCAG compliance via a single line of code — claims to solve accessibility quickly and cheaply. The reality is more complicated. Overlays have been named in dozens of lawsuits as themselves causing accessibility problems by interfering with users' assistive technologies. Several courts have rejected the argument that an overlay alone is enough to defeat a Title III claim.
Overlays may have a role as a complement to underlying remediation — for users who need to apply their own preferences over an already-accessible site — but they are not a substitute for fixing the underlying code. Plaintiffs' firms now specifically target sites running certain overlay products.
Document Everything for Defense
When a demand letter arrives, your defense strategy depends almost entirely on what you can prove about your accessibility program at the time of the alleged violation. Build a paper trail that includes:
- Dated audit reports showing scope and findings
- Remediation tickets with closure dates
- Vendor VPATs and accessibility conformance reports
- Training records for designers and developers
- Internal accessibility review checklists tied to product launches
- A change log for the accessibility statement
- User feedback received through your accessibility contact channel and your response to it
These records do not prevent lawsuits, but they shift settlement negotiations dramatically. A plaintiff hoping for a quick $10,000 nuisance settlement is far less interested when the defendant can produce a current audit, a documented remediation backlog, and a vendor VPAT for every embedded widget.
The Bookkeeping Side of Accessibility Compliance
Accessibility remediation is rarely a one-time expense. It usually shows up in your books as recurring spend — agency or contractor invoices for audits, software licenses for testing tools and monitoring services, design system rebuild costs, vendor switching costs, and the inevitable demand letter settlements that slip through despite your best efforts.
Tracking these expenses separately from general marketing or engineering spend makes a few things easier. You get a clean view of true compliance cost over time, which helps when budgeting next year's program. You document the spend if you later need to claim a deduction or amortize a capitalized website improvement. And if you ever face a serial-plaintiff class action, you can quickly produce a financial record of your good-faith investment in accessibility — useful in both settlement negotiations and any reasonable-modification defense.
A simple chart of accounts segment for "Accessibility compliance" with sub-categories for audits, remediation labor, testing tools, vendor due diligence, and settlement reserves goes a long way. Pair it with quarterly reviews so the program does not quietly drift off the budget.
Common Mistakes to Avoid
A few patterns appear in nearly every demand letter I see business owners receive.
Treating accessibility as a one-time project. Sites change constantly. A new product page, a redesigned checkout, an embedded chatbot — any of these can introduce fresh failures. Bake accessibility into your development lifecycle so every change is checked before it ships.
Relying entirely on automated scans. Automated tools catch a minority of WCAG failures. Manual testing with assistive technology is the only way to find issues like illogical focus order, misleading alt text, or unusable custom widgets.
Ignoring mobile apps. Title III plaintiffs increasingly file dual claims covering both website and native mobile app. iOS and Android each have their own accessibility APIs (UIAccessibility and TalkBack/AccessibilityService), and the same WCAG principles apply but require platform-specific testing.
Forgetting about PDFs. Tax forms, white papers, menus, and downloadable resources hosted on your site are all in scope. PDFs need proper reading order, tags, alt text, and form field labels just like HTML pages.
Assuming a third-party platform handles it for you. Shopify, WordPress, Wix, Squarespace, and similar platforms provide some accessibility scaffolding, but theme choices, custom code, embedded widgets, and the content you publish are still your responsibility. A demand letter does not care whether a theme came pre-built.
Skipping the accessibility statement. It costs nothing to publish and provides demonstrable evidence of good faith. The absence of one is sometimes cited specifically in complaints.
Keep Your Compliance Finances Organized from Day One
As you build your accessibility program, the supporting financial records — audit invoices, vendor agreements, remediation labor, training costs, and settlement reserves — need to live somewhere you can find them years from now if a serial plaintiff names your business. Beancount.io provides plain-text accounting that gives you complete transparency and version-controlled history over every line item, with no black boxes and no vendor lock-in. Get started for free and see why developers, finance teams, and compliance-conscious operators choose plain-text accounting to keep an audit-defensible record.