ADA website compliance in plain English

Published September 8, 2026 · about a 7-minute read

The letter usually arrives by email, and it's short. A law firm says a person using a screen reader couldn't complete a purchase on your site, that this violates the Americans with Disabilities Act, and that they'd like to discuss a settlement. No warning, no chance to fix it first. If you've never thought about accessibility, that email is a bad morning.

I want to cut through the fog around this, because most of what gets written about "ADA compliance" is either fear-selling or hand-waving. Here's what the law actually says, who's really getting sued, what standard you're held to, and what to do — without the legalese.

The ADA never mentions websites. Courts filled the gap.

The ADA was signed in 1990, years before most people had heard of the web. Title III of it covers "places of public accommodation" — stores, restaurants, banks, doctors' offices, anywhere the public does business. The text talks about physical spaces. It says nothing about HTML.

Courts have spent two decades deciding whether a website counts. The short version: they've mostly said yes, at least when the site connects to a business that serves the public. A few federal circuits still disagree about a purely online business with no physical location, so the answer isn't identical everywhere. But if you sell to U.S. customers, planning around "maybe it doesn't apply to me" is a bet I wouldn't take.

Who actually gets sued

Here's the part the scare-ads get right, for once. This is a real and growing wave. In 2025, plaintiffs filed 3,117 web accessibility lawsuits in federal court under Title III — up 27% from the year before, and the second-highest total on record. Add state courts, where many of these now land, and the count for the year tops 5,000. Web accessibility made up about 36% of all federal ADA Title III filings. The trend has more than tripled since 2017.

And it's not just the household-name brands. A lot of these suits target small and mid-sized businesses — e-commerce shops especially — often filed by a small number of very active plaintiffs and firms who scan sites at volume. You don't have to be big to be a target. You have to be reachable and testable, which every public website is.

The uncomfortable truth: your site is being audited whether you like it or not. The only question is whether you or a plaintiff's tester finds the problems first.

What standard are you held to?

This trips people up because there are two different answers depending on who you are.

Private businesses (Title III): there's no federal regulation that spells out exact web rules. In the vacuum, courts and settlements have converged on one yardstick — the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. It's not a statute, but it's the de facto bar, and settlement agreements routinely name it.

State and local government (Title II): here it is a rule. In 2024 the Department of Justice finalized a regulation requiring government websites and apps to meet WCAG 2.1 AA, with compliance deadlines phased by population size. If you work with public-sector clients, that one has teeth and dates.

Best practice now is the newer WCAG 2.2 AA, which became a W3C Recommendation in October 2023 and adds a handful of criteria on top of 2.1. I wrote a practical WCAG 2.2 AA checklist that walks through what's new in normal-website terms.

The overlay trap

You'll see ads for accessibility "overlays" — a widget you drop in with one line of script that promises instant compliance. Be careful. These tools sit on top of your page and toggle a few preferences (bigger text, higher contrast). They do not rewrite the underlying code, and they can't fix a button that has no label or an image with no alt text. Sites running these widgets have still been sued, sometimes because the overlay itself got in the way of a screen reader.

An overlay is a convenience feature, not legal armor. If a vendor tells you a script makes you "ADA compliant," that's the sentence that should make you close the tab.

What to actually do

Real accessibility lives in the markup, not a widget. The highest-leverage fixes, in rough order:

• Alt text on meaningful images. Describe what the image conveys. Decorative images get alt="" so screen readers skip them.
• Every control has a name. Buttons, links, and form fields need text or a label a screen reader can announce. An icon-only button with no label is invisible to a blind user.
• Keyboard operability. Tab through your whole site without a mouse. If you can't reach the menu, the cart, or the checkout with a keyboard, neither can a lot of your visitors.
• Visible focus. The element you've tabbed to must be clearly outlined. Don't strip focus styles for looks.
• Color contrast. Body text needs a 4.5:1 contrast ratio against its background. Light-grey-on-white fails constantly.
• Real headings and labels. Use <h1>…<h2> in order and pair every input with a <label>. Structure is how non-visual users navigate.

Then get an automated scan to catch the obvious machine-detectable failures — missing alt text, unlabeled fields, contrast problems — and fix those before a tester does. Automated tools catch maybe a third of all issues, so pair them with a manual keyboard pass, but they're the fastest way to clear the low-hanging fruit that shows up in most demand letters. Our free accessibility checker runs that scan against your live page and grades it, no signup.