ADA Website Compliance: The Complete 2026 Guide
Approximately 3,117 federal web accessibility lawsuits were filed in 2025, a 27% increase over 2024. Add state court filings and the total exceeded 5,00..
Approximately 3,117 federal web accessibility lawsuits were filed in 2025, a 27% increase over 2024. Add state court filings and the total exceeded 5,000 cases. That is not a spike. That is a trend with no sign of reversing.
Most business owners assume ADA website compliance is either too technical to manage or a problem reserved for Fortune 500 companies with legal departments. Neither is true. The businesses getting sued are restaurants, boutique e-commerce stores, local service providers, and regional retailers. Exactly the kinds of operations that assume they are too small to be a target.
What makes this genuinely difficult is the absence of a clear government deadline. There is no date on the calendar that makes you compliant or non-compliant. Enforcement is entirely lawsuit-driven, which means exposure is constant and the warning shot comes from a plaintiff’s attorney, not a regulator. This guide explains what the law actually requires, which businesses face the most risk, what the most dangerous shortcuts will cost you, and how to run a compliance process that holds up.
Why Web Accessibility Lawsuits Kept Rising in 2025 – and What That Means for Your Business
The numbers from UsableNet’s 2025 Year in Review are worth sitting with. Roughly 3,117 federal ADA web accessibility cases were filed in 2025, up 27% from 2024. State filings pushed the real total past 5,000. These are not regulatory fines or agency actions. Every single one started with a plaintiff, an attorney, and a demand letter.
The economics of ADA web litigation explain the volume. Many cases settle quickly for $5,000 to $25,000, sometimes more, plus legal fees and remediation costs. Plaintiffs’ firms have built repeatable playbooks: scan a site, identify failures, send the letter. Lower friction to file means more filings.
For your business, the key fact is that there is no complaint threshold you have to cross before being targeted. A site does not need to be egregiously broken. A missing image description on a product page, an unlabelled checkout form field, a PDF that cannot be read by a screen reader: these are the kinds of failures that trigger demand letters every week.
The trajectory is clear. If your site has never been audited for accessibility, the question is not whether it has failures. It almost certainly does. The question is whether you find them first.
If you want to see where your site stands before reading further, scan your site free at accessibilityscanner.org for an immediate picture of detectable failures.
What the ADA Actually Requires from Your Website
Here is the legal reality most businesses never hear stated plainly: ADA Title III has no government-set deadline for web accessibility compliance. The Department of Justice did not set one. Congress did not set one. There is no date by which you must comply or face a fine from a government body.
Courts filled the gap themselves. Consistent judicial decisions across multiple federal circuits have applied WCAG 2.1 Level AA as the enforceable standard for private business websites. According to ADA.gov’s guidance on web accessibility, Title III requires that businesses open to the public, which courts have consistently interpreted to include websites, do not discriminate against people with disabilities. In practice, that means WCAG 2.1 AA compliance.
WCAG 2.1 AA is a technical specification published by the W3C. It covers four categories:
- Perceivable. Content must be presentable in ways users can perceive. Images need text alternatives. Videos need captions. Colour cannot be the only way information is conveyed.
- Operable. All functionality must work by keyboard, not just mouse. Navigation must be predictable. Users must have enough time to interact with content.
- Understandable. Text must be readable. Forms must give clear instructions and describe errors. Behaviour must be consistent.
- Robust. Content must work with current and future assistive technologies, including screen readers.
None of this is aspirational guidance. Because courts have applied this standard in binding decisions, failing WCAG 2.1 AA means failing the legal test if you end up in front of a judge. The absence of a government deadline does not create a safe harbour. It creates unpredictability, which is worse.
Section 508 of the Rehabilitation Act is a separate law that applies to federal agencies and their contractors. If you build software or websites for a federal client, Section 508 applies to you directly. For private businesses with no federal contracts, it is background context, not your compliance target.
Which Industries and Sites Are Most at Risk
Every industry has exposure, but the distribution is not even. According to UsableNet’s 2025 data, e-commerce accounts for approximately 70% of all web accessibility lawsuits filed in the United States. The reasons are structural: product pages, checkout flows, and account management interfaces create dozens of interaction points where accessibility failures compound.
Restaurants and food-service businesses were the single most-targeted industry in 2025. Online menus, reservation systems, and ordering integrations are common failure points, and the volume of small operators in that sector makes it easy for plaintiff firms to scale their approach.
Beyond those two, the industries consistently appearing in filings include retail and consumer goods, healthcare and medical practices, entertainment and hospitality, and professional services with online booking or client portals.
The pattern is not industry-specific complexity. It is the presence of user-interaction features: forms, checkout, scheduling tools, combined with sites that were built for speed and aesthetics rather than accessibility. If your site has any functional layer beyond static content, your risk profile is real.
Small and mid-sized businesses are disproportionately represented in filings. Large enterprises responded to earlier legal pressure with dedicated accessibility programmes. The gap is in the middle of the market.
The Overlay Myth: Why a Widget Is Not a Compliance Strategy
Accessibility overlays are JavaScript widgets that claim to add compliance to any site without touching the code. They are also an active legal liability.
According to UsableNet’s 2025 Year in Review, approximately 22.6% of web accessibility lawsuits filed in 2025 targeted websites that already had an accessibility overlay or widget installed. Nearly one in four defendants had paid for a product specifically marketed to prevent this outcome. It did not work.
The regulatory picture is equally clear. The FTC reached a settlement with accessiBe, one of the largest overlay providers, requiring the company to pay $1 million over misleading marketing claims that its product guaranteed ADA compliance and protected clients from lawsuits. The FTC’s position: those claims were false.
Overlays fail because they inject a JavaScript layer on top of your existing HTML. They can adjust some visual settings and add some ARIA labels, but they cannot fix broken keyboard navigation, restructure poor heading hierarchies, re-caption un-captioned video, or make a fundamentally inaccessible PDF readable. Screen reader users frequently report that overlays make sites harder to use, not easier.
The lawsuit data and the FTC settlement tell you what that investment actually buys. If you have an overlay installed, it does not replace a compliance process. If you are considering one, now you know.
What Automated Scanning Catches – and What It Misses
According to the WebAIM Million 2025 Annual Report, 94.8% of the top 1 million home pages contain detectable WCAG 2 A/AA failures. The word “detectable” matters. These are failures that automated tools can find reliably and fast.
Starting with a free ADA compliance checker gives you an immediate view of your site’s detectable failure profile. That is the right first step. But understanding what you are getting, and what you are not, is what separates a useful audit from a false sense of security.
What automated scanners reliably catch:
- Missing or empty image alt text
- Low colour contrast between text and background
- Missing form labels (inputs with no associated label element)
- Missing document language declaration
- Duplicate page titles or missing headings
- Broken skip navigation links
These six categories account for the vast majority of automated detections and appear on nearly every non-compliant site. Finding and fixing them addresses a significant portion of your risk.
What automated scanners cannot catch:
- Keyboard traps, where a keyboard-only user gets stuck inside a modal or widget with no way out
- Screen reader announcement logic, whether dynamic content updates are communicated correctly to assistive technology
- Cognitive load issues, whether form error messages are usable under pressure
- Whether captions are accurate, not just present
- Whether a PDF’s reading order makes sense to a screen reader
Manual testing, including testing with an actual screen reader like NVDA or VoiceOver, is required for complete coverage. A compliance process that relies solely on automated scanning is not a compliance process. It is a starting point.
Your Step-by-Step ADA Compliance Process
The average home page has 51 distinct accessibility errors, according to the WebAIM Million 2025 Annual Report. That is down from 56.8 in 2024. Progress, but 51 errors per page still represents a systemic problem. A working compliance process looks like this:
Step 1: Scan
Run automated scans on your key pages: home page, product and service pages, contact and booking forms, checkout flow, and any PDF documents linked from the site. Use a tool that reports against WCAG 2.1 AA criteria specifically. This gives you a concrete issue list, not a vague score.
Step 2: Prioritise
Not all failures carry the same risk. Prioritise issues that block task completion first: a checkout form that cannot be submitted by keyboard, a login field with no label, an image carousel that traps focus. Colour contrast failures are common and important, but a sighted user who struggles with low contrast is still able to complete a task. A keyboard user stuck in a broken modal is not. Work through your issue list in order: functional blockers first, then high-frequency pages, then WCAG Level A failures, then Level AA.
Step 3: Remediate
Assign fixes to your development team with specific WCAG success criteria referenced for each issue. Fixes go into your actual codebase, not patched by an overlay. For most teams, common fixes include adding alt attributes to images, associating <label> elements with form inputs, ensuring heading hierarchy is logical, and adding lang attributes to the HTML element. Your developer does not need to understand every corner of WCAG. They need a clear issue list with references.
Step 4: Test with assistive technology
After remediation, test the repaired pages manually. Use NVDA with Firefox or VoiceOver with Safari as a minimum. Navigate your forms, checkout flow, and interactive components using only the keyboard. Confirm that screen reader announcements make sense. This step cannot be skipped. It catches what scanners miss.
Step 5: Document
Keep a record of what you scanned, what you found, what you fixed, and when. This documentation serves two purposes. First, it demonstrates good-faith effort, which matters in litigation. Second, it gives you a baseline to detect new issues introduced by future site changes. A simple spreadsheet tracking issue, WCAG criterion, fix applied, and date resolved is sufficient.
Step 6: Maintain
Accessibility does not stay fixed. Every time you add a product, update a page template, install a new plugin, or change your CMS theme, you risk introducing new failures. Schedule automated scans monthly at minimum. Run a manual review after any significant site update. Treat accessibility the same way you treat security: an ongoing discipline, not a one-time project.
Ongoing Compliance: Why a One-Time Fix Is Not Enough
A developer remediates your site in Q1. By Q3, a new blog template has launched, three new product images have been added without alt text, and a third-party booking widget has been embedded that has never been tested with a screen reader. Your site is no longer where it was after the remediation.
This is the default trajectory for any site without an accessibility maintenance programme. Content changes, plugin updates, CMS migrations, and A/B test implementations all introduce failure risk. The fix-once approach works until the site changes, and sites change constantly.
The practical response is to make accessibility part of your standard QA process: automated scanning as part of deployment checks, accessibility criteria included in content guidelines, periodic manual reviews on a defined schedule. This does not require a dedicated accessibility team. It requires a process. The businesses that defend themselves most effectively against web accessibility claims are the ones that can demonstrate continuous, documented effort, not a single audit performed two years ago.
A Note on Other Laws: EAA, Section 508, and International Obligations
ADA Title III is the primary concern for US-based private businesses, but it is not the only law in play.
If your business sells products or services to customers in the European Union, the European Accessibility Act (EAA) applies to you. It came into force on June 28, 2025, and requires compliance with WCAG 2.1 AA standards. It applies to any company with 10 or more employees or €2 million or more in annual turnover that sells into EU markets. This is not a future requirement. It is in effect now.
Section 508 applies to federal agencies and their contractors. If you build, procure, or maintain digital products for a US federal government client, Section 508 is your compliance standard. The technical requirements largely align with WCAG 2.1 AA, but the regulatory framework and enforcement mechanism are different from ADA Title III.
If you operate across multiple jurisdictions, get legal advice specific to your situation. The compliance baseline, WCAG 2.1 AA, is consistent across these frameworks, which means remediating against that standard addresses the core requirement in most cases.
This article is for general informational purposes and is not legal advice.
Start With a Baseline
The compliance process described above starts with a scan. Everything else, prioritisation, remediation, testing, documentation, depends on knowing what your site currently contains.
Run a free scan at accessibilityscanner.org to get an immediate view of your site’s detectable WCAG 2.1 AA failures. It will not replace a manual audit or a developer review. But it will tell you what you are working with, and that is the only honest place to start.