ADA Compliance for Websites: The 2026 Guide

Here is the uncomfortable reality behind ADA compliance for websites in 2026: the accessibility of the average website has barely improved, while the legal pressure on the businesses that own those websites has never been higher. According to the WebAIM Million — the largest annual audit of the web — 95.9% of the top one million home pages have detectable WCAG failures, with an average of 56 accessibility errors on every page. At the same time, more than 5,000 digital accessibility lawsuits were filed across state and federal courts in 2025.

If you run a business website, that combination is the whole story. Non-compliance is the norm, which means it is also the target. This guide explains what the law requires, why the "quick fix" most owners reach for actually increases their risk, the specific technical issues that trigger the majority of complaints, and the practical path to getting — and staying — compliant.

What "ADA compliance for websites" actually means

The Americans with Disabilities Act (ADA), signed in 1990, prohibits discrimination against people with disabilities in "places of public accommodation." When the law was written, that meant physical spaces — ramps, doorways, restrooms. It said nothing about websites, because the commercial web did not exist yet. For more than three decades, courts have been closing that gap, and the dominant interpretation today is that a business's website is an extension of its public accommodation. If the public can buy from you, book with you, or get information from you online, that experience has to be usable by people with disabilities.

In practice, "usable by people with disabilities" means the site works for someone who cannot see the screen and navigates by screen reader, someone who cannot use a mouse and navigates by keyboard, someone with low vision who needs sufficient contrast, and someone who is deaf or hard of hearing and needs captions. ADA web compliance is not a design aesthetic or a badge — it is whether these real interactions succeed or fail.

To make that concrete: imagine a customer using a screen reader tries to buy from your store. The product photos have no alt text, so she has no idea what she is looking at. The "Add to cart" control is an unlabeled icon, so her screen reader announces only "button." The checkout fields show faint placeholder text but no real labels, so she cannot tell which box is the email and which is the ZIP code. Each of those is a common, machine-detectable WCAG failure — and together they mean she simply cannot finish a purchase she was ready to make. That is what an inaccessible website is in practice: not an abstract standard, but a locked door on a specific transaction.

Title II vs Title III — and the WCAG standard courts use

The ADA is divided into titles. Title II covers state and local governments and their instrumentalities — public schools, universities, transit, courts. Title III covers private businesses that serve the public — virtually every commercial website. The distinction matters because the two now sit on different legal footing.

On April 24, 2024, the Department of Justice published a final Title II rule that, for the first time, names an explicit technical standard: WCAG 2.1 Level AA. Government entities must conform, with compliance dates phased through 2027–2028 for smaller entities. Title III — private business — still has no regulation naming a standard. But that is not the reassurance it sounds like: in the absence of a codified rule, courts have overwhelmingly adopted WCAG 2.1 Level AA as the working definition of an accessible site. So whether you are a county government or a Shopify store, the finish line is the same set of guidelines.

How websites came under the ADA: the cases that set the precedent

Because websites were never written into the 1990 statute, their inclusion has been built case by case — and a handful of decisions did most of the work. Understanding them explains why "there's no regulation for private business" is not the defense it sounds like.

The most consequential is Robles v. Domino's Pizza. A blind customer, Guillermo Robles, could not complete an order on Domino's website or app using his screen reader. In 2019 the Ninth Circuit held that the ADA applies to the website and mobile app of a business with a physical presence — and, critically, that a business can be held liable even though the government has never issued website accessibility regulations. In October 2019 the U.S. Supreme Court declined to hear Domino's appeal, leaving that ruling intact. On remand, the court found Domino's in violation. It remains the closest this issue has come to the Supreme Court, and the reason the "no rules yet" argument fails in court.

The template was set earlier, in National Federation of the Blind v. Target (2008) — the first major e-commerce accessibility case — which ended in a $6 million class-action settlement and established that an online store could be sued for being inaccessible. Together these cases created the "nexus" theory most courts now follow: if your website connects to the goods or services you offer the public, it has to be accessible to the public.

WCAG 2.1 or 2.2 — which version applies to you?

You will see two version numbers referenced, and it is worth knowing the difference. WCAG 2.1 (2018) is the version U.S. courts cite and the one the DOJ's 2024 Title II rule formally adopts. WCAG 2.2, published by the W3C in October 2023, is the current version. It keeps everything in 2.1 and adds nine new success criteria aimed at more recent problems: keeping keyboard focus visible, minimum target sizes for touch, alternatives to dragging, consistent help placement, less redundant re-entry of information, and more accessible authentication.

Because 2.2 is backward-compatible, conforming to 2.2 automatically satisfies 2.1. The practical guidance is simple: treat WCAG 2.1 AA as your legal floor and WCAG 2.2 AA as your target. You get current best practice and full coverage of the standard courts reference, with no downside.

The 2026 lawsuit landscape: who is getting sued, and where

Website accessibility litigation is not a fringe risk — it is one of the fastest-growing categories of civil suit in the country. In 2025, website accessibility accounted for roughly 3,100 federal filings, about 36% of all ADA Title III lawsuits — up from 28% the year before. Add state courts (New York's in particular) and the total tops 5,000 digital accessibility suits for the year. Since 2018, more than 25,000 such cases have been filed. And filed lawsuits are only the visible tip: an estimated 35,000–50,000 demand letters — the private settlement demands that never reach a courtroom — were sent in 2025.

The targeting is not random. Filings concentrate heavily by industry and by state:

Geographically, four states dominate: New York, Florida, California and Illinois together account for roughly two-thirds of all federal website accessibility filings, driven by plaintiff-friendly case law and active firms that file in volume. But a demand letter can reach a business in any state — the plaintiff's location, not yours, sets the venue. If you sell nationwide, you are exposed nationwide.

Who files these lawsuits — and why small businesses are the target

A common misconception is that only large corporations get sued. The data says the opposite. Website accessibility cases are driven by a relatively small number of plaintiffs and law firms who file in high volume — sometimes hundreds of near-identical complaints in a year. Their process is industrialized: run an automated scan across a long list of sites, flag the machine-detectable failures, and send a demand letter or file suit. Because those failures are provable by a tool, the cases are cheap to bring and expensive to defend.

That economics is exactly why small and mid-sized businesses are frequent targets rather than the big brands with in-house legal teams. A smaller business is more likely to settle quickly to make the problem disappear — and each quiet settlement funds the next batch of letters. Being small is not protection; in this arena it is part of the appeal. And because the same handful of failures appear on the majority of websites, a plaintiff needs to know nothing about your business to find a violation on your site.

State laws that raise the stakes

The ADA is the federal baseline, but several states stack additional exposure on top — which is a large part of why filings cluster where they do. The most significant is California's Unruh Civil Rights Act. It treats any ADA violation as a state violation and carries statutory damages of at least $4,000 per violation, meaning a plaintiff does not have to prove any financial loss to recover. That single provision is a major reason California is one of the busiest venues in the country.

New York's State and City Human Rights Laws similarly give plaintiffs strong footing, and New York leads the nation in website accessibility filings. The pattern extends well beyond the U.S., too: Canada's AODA, the EU's European Accessibility Act (in effect since June 28, 2025), and the U.S. federal Section 508 all point to WCAG Level AA as the standard. If you sell internationally, that convergence is good news — WCAG 2.1 / 2.2 AA is effectively a universal passport, and the same remediation work satisfies most of these regimes at once.

The widget fallacy: why overlays get sued anyway

When a business owner first learns about ADA web risk, the instinct is to find the fastest possible fix — and an entire industry exists to sell exactly that: an accessibility overlay, a single line of JavaScript that drops a widget onto the site promising instant compliance. It is the most dangerous purchase in this space, because it treats a code problem as a bolt-on.

Overlays sit on top of your site at runtime. They do not rewrite the underlying HTML that a screen reader actually reads — the missing alt attributes, the unlabeled form fields, the empty links are all still there in the source. Assistive technology reads the source, not the marketing. That is why plaintiffs increasingly target overlay-equipped sites on purpose: in the complaints, the widget is cited as a barrier, not a solution.

The takeaway is not that automation is bad — it is that a widget layered over broken code cannot fix the code. Real compliance means correcting the source: the alt text, the labels, the contrast, the keyboard paths. That is what the next section is about. We cover the overlay problem in depth here.

The six failures behind 96% of detected errors

The most useful finding from the WebAIM Million is how concentrated the problem is. Across a million home pages, just six failure types account for 96% of all detected WCAG errors. These are also the issues that automated scanners and serial plaintiffs' tools flag first, because they are unambiguous and machine-detectable. Fix these six and you eliminate the vast majority of your measurable exposure.

What "enough contrast" actually looks like

Low-contrast text is the single most common failure on the web — present on 83.9% of home pages. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text (3:1 for large text). Here is the difference at a glance, all on a white background:

Level AA is the benchmark U.S. courts reference. If your brand palette uses light gray text, pale buttons or low-contrast placeholders, it is almost certainly failing this test somewhere.

The fixes, in code

Most of these failures are small, mechanical corrections. Two of the most common, shown wrong then right:

<!-- Fails: screen reader announces nothing useful -->
<img src="/team.jpg">

<!-- Passes: describes the image -->
<img src="/team.jpg" alt="Our five-person support team at the front desk">

<!-- Fails: no label, screen reader says "edit text" -->
<input type="email" placeholder="Email">

<!-- Passes: label is tied to the input -->
<label for="email">Email address</label>
<input type="email" id="email">

<!-- Fails: screen reader announces only "link" -->
<a href="/cart"><svg>...</svg></a>

<!-- Passes: the icon's purpose is named, icon hidden from AT -->
<a href="/cart" aria-label="View your cart">
  <svg aria-hidden="true">...</svg>
</a>

For a fuller walkthrough, see our guides on alt text requirements and color contrast requirements.

It's not just web pages: apps, PDFs and third-party tools

One reason overlays and one-time fixes fall short is that ADA web compliance reaches further than your marketing pages. Three areas are routinely overlooked — and routinely litigated.

Mobile apps are squarely included. Robles v. Domino's was about the app as much as the website. If customers can browse, book or buy in your app, it has to work for screen-reader and switch users just like your site does.

PDFs are a frequent blind spot. Menus, order forms, brochures, statements and reports posted as PDFs must be properly tagged and readable by assistive technology. An untagged PDF is often just as inaccessible as an unlabeled web form — and just as actionable.

Third-party components count against you. The booking widget, chat box, payment iframe or review carousel you embedded is part of your visitor's experience. If it is inaccessible, your site is inaccessible — regardless of who built it. Vet vendors for accessibility before you integrate, and always test the whole rendered page, not just the code your own team wrote.

How a demand letter becomes a lawsuit

Most claims follow a predictable path. Knowing it helps you respond calmly instead of panicking if a letter lands:

1. 1The scan. A plaintiff's automated tool flags machine-detectable failures on your site — often as part of a batch across hundreds of businesses.
2. 2The demand letter. A law firm sends a letter alleging ADA (and often state-law) violations, usually naming a settlement figure and a remediation deadline. Many cases never go further than this.
3. 3The negotiation window. You respond — ideally through counsel. Documented, good-faith remediation already underway materially strengthens your position here.
4. 4The lawsuit. If the letter is ignored or unresolved, a formal complaint is filed. Costs escalate sharply and the matter becomes public record.
5. 5Settlement or judgment. The overwhelming majority settle — almost always with a binding commitment to fix the site and keep it accessible.

The single most important takeaway: at every stage, your leverage comes from the site actually being fixed. You cannot un-send a letter, but you can change what it is worth by remediating — which is exactly why scanning and fixing before anything arrives is the cheapest insurance available.

What non-compliance actually costs

The financial risk escalates the further a claim travels. It rarely starts with a courtroom — it starts with a letter. Understanding the ladder helps you see why fixing the site early is almost always cheaper than the alternative:

Note what is not optional in any of these outcomes: remediation. Even after you pay a settlement, you still have to fix the website — the exact work you could have done up front for a fraction of the cost, without the legal fees, the deadline pressure, or the public filing. If a letter has already arrived, our demand-letter response guide walks through what to do first.

The business case beyond the lawsuit

Framing accessibility purely as legal defense undersells it. An inaccessible website does not just invite a lawsuit — it quietly turns away a very large, very loyal, and very underserved market every single day.

More than 70 million U.S. adults — one in four — live with a disability, according to the CDC, and globally the World Health Organization counts 1.3 billion people. In the U.S. alone, this community commands an estimated $490 billion in disposable income. And they vote with their clicks: in consumer research, roughly 69% of users with disabilities say they will immediately leave a website they find difficult to use — a bounce you never see and never get a second chance at.

There is a compounding benefit, too. The same fixes that make a site accessible — descriptive alt text, clean heading structure, real link text, proper labels — are the fixes that make a site more legible to search engines. Accessibility and SEO pull in the same direction.

Common myths about ADA web compliance, debunked

A lot of avoidable risk comes from a few persistent misconceptions. Here are the ones that get businesses into trouble most often:

How to check and fix your website

You do not need to guess where you stand. The workflow is straightforward: scan, prioritize, fix, verify, and then keep watching — because every redesign, plugin update, and new landing page can reintroduce issues.

1. Scan against WCAG 2.1 AA. An automated scan catches the machine-detectable majority — contrast, alt text, labels, empty links and buttons — in seconds, and gives you a prioritized list.
2. Confirm what machines can’t. Tab through the whole site with a keyboard, and try it with a screen reader (VoiceOver on Mac, NVDA on Windows are free). Automation finds most issues; humans confirm the experience.
3. Fix the highest-impact issues first. Start with anything blocking a core task — checkout, contact, booking. Those are what plaintiffs test and what customers abandon.
4. Document your good-faith effort. Keep a record of what you scanned and fixed. Documented remediation is exactly what reduces exposure when a demand letter arrives.
5. Re-scan on a schedule. Accessibility is not a one-time project — it is a maintenance habit. Monitor after every change.

The quick self-audit checklist

• Every image has a meaningful alt attribute (or alt="" if decorative).
• All text meets a 4.5:1 contrast ratio against its background.
• Every form field, search box and checkout input has a visible or programmatic label.
• The whole site works with a keyboard alone — Tab, Enter and Escape, no mouse.
• A visible focus outline shows where the keyboard is on the page.
• Links and buttons have real text or an accessible name — no empty ones.
• Headings are in logical order (one H1, then H2s and H3s that nest correctly).
• The page declares its language with <html lang="…">.
• Video has captions and audio has a transcript.
• You re-scan after every redesign, plugin update or new landing page.

The bottom line

ADA compliance for websites is not a badge you buy or a plugin you install — it is whether real people with disabilities can use your site to do the thing they came to do. The law has settled enough that "there were no rules" protects no one; the litigation is voluminous and industrialized; and the technical bar, while real, comes down to a short list of fixable failures. The businesses that stay out of trouble are not the ones with the fanciest tools — they are the ones that scan regularly, fix the underlying source code, and keep a record of having done so. That is entirely achievable, and it starts with knowing exactly what is on your site today.