Website Accessibility: What ADA Compliance Actually Requires

Website accessibility gets sold to small businesses through fear, usually by a company selling a widget. The pitch is that you are one demand letter away from disaster and that a line of JavaScript will protect you.

The legal exposure is real. The widget does not protect you, and in a meaningful share of cases it appears to attract the lawsuit rather than prevent it.

Here is what the law actually says, what it does not say, and what to do about it.

This is a practical guide, not legal advice. If you receive a demand letter, talk to an attorney rather than acting on anything you read online, including this.

What the law actually requires

This is genuinely confusing because there are several different regimes and people mix them up constantly.

ADA Title III covers private businesses open to the public. There is no federal regulation naming a specific technical standard for private business websites. That sounds like good news and mostly is not, because in the absence of a codified rule, courts have overwhelmingly adopted WCAG as the working definition of an accessible site. You get the obligation without the clarity.

ADA Title II covers state and local government. Here the Department of Justice published a final rule in April 2024 that, for the first time, names an explicit standard: WCAG 2.1 Level AA. Compliance deadlines were subsequently extended, with larger public entities now facing a 2027 date and smaller entities and special districts a 2028 date. The dates moved. The standard did not.

Section 508 covers federal agencies and their vendors. If you sell to the federal government, this applies to you through your contracts.

Section 504 reaches healthcare providers receiving federal funding, with its own conformance requirement and timeline.

State law adds exposure independently. California’s Unruh Act and New York’s statutes are the ones that come up most often, and they can carry damages that federal ADA claims do not.

The practical synthesis: whether you are a county government with a codified deadline or a plumbing company with none, the finish line everyone is measured against is the same set of guidelines.

WCAG in plain terms

The Web Content Accessibility Guidelines are maintained by the W3C. Three things to know.

Versions. 2.0, 2.1, and 2.2 exist. 2.1 Level AA is the legal floor most often cited. 2.2 is the current recommendation and is backward compatible, so meeting 2.2 means meeting 2.1 and 2.0.

Levels. A is the minimum, AA is where law and practice meet, AAA is aspirational and not the target for most sites.

Principles. Everything rolls up to four ideas, usually abbreviated POUR. Content must be Perceivable, Operable, Understandable, and Robust.

The overlay problem

Accessibility overlays are widgets you add with one line of code that promise to make a site compliant automatically. They are heavily marketed and they do not work.

The reason is structural. An overlay runs on top of your existing code. It does not fix the underlying HTML that a screen reader actually reads, so the barriers remain for the people who need accommodation. Users of assistive technology have been vocal about this for years, and some find overlays actively interfere with the tools they already use.

Two facts worth knowing before you buy one.

In April 2025, the FTC finalized a $1 million order against a major overlay vendor over claims that its automated product could make a website WCAG compliant. The order bars making that claim without evidence.

And a substantial share of website accessibility lawsuits filed in recent years have targeted sites that already had an overlay installed. Published analyses put it somewhere around a fifth to a third of cases. Plaintiffs’ firms appear to treat an overlay as a signal that a site has a compliance problem the owner tried to paper over, which is close to the opposite of what the widget was purchased for.

An overlay is not a legal shield. If you have one, it should sit alongside real remediation rather than in place of it.

The scale of the litigation, honestly

Federal website accessibility filings have been running in the low thousands per year and growing, with a much larger volume of demand letters that never become filings. eCommerce sites are the most frequent target by a wide margin.

Most of these cases never see a courtroom. They settle, typically in the five-figure range plus attorney fees. The cost of responding reactively to a demand letter, combining legal fees with emergency remediation, generally runs several times the cost of doing the work proactively.

The trend worth noting is that automated scanning tools have made it trivially cheap to identify non-compliant sites at scale, which is why filing volume keeps rising rather than plateauing.

Where the actual problems are

WebAIM’s annual analysis of a million homepages consistently finds detectable WCAG failures on the overwhelming majority of them, and a handful of error types account for almost all detected failures.

Which is good news, because it means most of the risk concentrates in a short list.

1. Low contrast text. Light grey on white is the single most common failure on the internet. Designers like it. It fails.
2. Missing alt text on images. Every meaningful image needs a description. Decorative images should be explicitly marked as decorative rather than left blank ambiguously.
3. Unlabeled form fields. A field with placeholder text but no programmatic label is unusable with a screen reader. Your contact form is probably doing this.
4. Empty links and buttons. An icon-only button with no accessible name announces as nothing at all.
5. Missing document language. A one-attribute fix that tells assistive technology which language to read in.
6. Broken heading structure. Headings chosen for size rather than hierarchy. Screen reader users navigate by headings, so a page with no H1 or six of them is genuinely hard to use.

Fix those six across your templates and you have addressed the large majority of what an automated scan will find on a typical small business site.

What to actually do, in order

Run a free scan first. WAVE from WebAIM is free, browser-based, and will show you concrete errors on any page. Run your homepage, a service page, and your contact page.

Understand the limit of that scan. Automated tools catch roughly a third of real issues. They find contrast and missing labels. They cannot tell you whether your navigation makes sense with a keyboard or whether your alt text is useful rather than merely present.

Do the manual checks. Unplug your mouse and navigate your own site with the Tab key. Can you reach everything? Can you see where you are? Can you complete the contact form and submit it? Can you close a popup? That ten-minute exercise finds problems no scanner will.

Fix in the templates, not page by page. Most failures are systemic. Correcting the contrast in your theme fixes it on every page at once.

Publish an accessibility statement. State your conformance target, acknowledge that you may not be perfect, and give a real contact method for anyone who hits a barrier. This is not legal protection, but a business that responds promptly to a complaint is in a materially better position than one that ignores it.

Build it into the process. Accessibility is not a project that finishes. Every new page and every new plugin can introduce barriers. Add a check to whatever your publishing routine is.

The argument nobody makes

Everything above is framed around risk, because that is how the topic gets sold. There is a better reason.

A meaningful share of the population has a disability affecting how they use the web, and that share grows as the population ages. Anyone who has watched a parent struggle with small grey text on a phone has seen the practical version of this.

Most accessibility work also produces a better site for everyone. Higher contrast is easier to read outdoors. Proper headings make pages scannable. Captions serve the majority of people watching video with the sound off. Clean semantic structure is exactly what search engines and AI systems need to parse a page, which we covered in our piece on getting cited by AI engines.

It is unusual for a compliance obligation to overlap this cleanly with things you would want to do anyway.

We build websites with this in mind rather than bolted on afterward, and we do not sell overlays. If you want a straight read on where your site currently stands, send us the URL.