What US Web-Accessibility Law Actually Requires

Someone eventually tells you your site has to be accessible "by law," and usually they are selling something. The truth is stranger and more useful than either the scare or the shrug: for a private business website in the United States there is no government technical rule to follow and no compliance date to miss — and that is exactly why the risk is real. The requirement is not written down as a spec. It is being written, case by case, in court.

There is no technical rule, and no deadline

The Americans with Disabilities Act is from 1990. Title III of it covers "places of public accommodation" — the shops, restaurants, clinics, and offices open to the public. It says nothing about HTML, because in 1990 there was none to say anything about.

The Department of Justice has since issued a technical standard for websites, and it is the single most misquoted fact in this whole subject: that rule is written under Title II, and Title II is state and local government. It names WCAG 2.1 Level AA, and it carries real compliance dates — for county websites, city portals, public school districts and public universities. If you run a bakery, a law practice, a SaaS product or a side project, that rule is not addressed to you and those dates are not yours.

For a private business there is no equivalent DOJ technical rule. There was a rulemaking aimed at one, and the Department withdrew it in 2017 without replacing it. So if a vendor emails you a deadline, ask them to name the rule and the section it comes from. Either they are quoting the Title II dates at somebody Title II does not cover, or they are quoting nothing.

The honest answer to "is my site legally required to be accessible?" is therefore an awkward one: in practical terms yes — and the requirement is not written down anywhere as a technical standard you can look up and satisfy.

What fills the gap: litigation, and WCAG 2.1 Level AA

What fills the gap is lawsuits. When a US court decides one of these cases, and when the DOJ writes a settlement agreement to resolve one, the benchmark they have generally reached for is the Web Content Accessibility Guidelines — specifically WCAG 2.1 Level AA, published by the W3C, not by any government.

That makes WCAG 2.1 AA the de facto standard: not because a statute names it for you, but because it is what you will be measured against if you are ever measured. It is a published document anyone can read, it is free, and it is written as testable success criteria rather than as principles. Working toward it is the most useful thing you can do with the uncertainty.

Note the shape of that sentence. Working toward a standard is something you can say about yourself. Having arrived is a conclusion somebody else draws after testing your actual pages — which is the distinction the rest of this article keeps coming back to.

The numbers, and where they are soft

Every figure in this section comes from private litigation trackers — the annual counts that accessibility vendors and defense-side law firms publish each year. We took them from a research brief compiled for this project on September 12, 2026, and we have not pulled the federal dockets ourselves to check them. Read them as an order of magnitude.

• 3,117 US federal web-accessibility lawsuits filed in 2025, reported as up 27% on 2024. That is a count of filings, so it is the hardest number here — a case either has a docket number or it does not.
• An estimated 35,000–50,000 demand letters over the same period. This one is a genuine estimate and the range is wide for a structural reason: a demand letter never reaches a docket, so nobody can count them, and the trackers are extrapolating from what their own clients received.
• Settlements reported in the range $5,000–$75,000, plus attorney fees, plus remediation — the remediation being the part that is neither optional nor capped, and usually the part that costs more than the settlement.

Why the trackers disagree with each other, which matters more than any single figure: they are not counting the same thing. Some count only web-specific filings, some count all ADA Title III filings including physical premises, some add state court and some do not, and the year boundary moves depending on whether a case is dated by filing or by service. Two reports can differ by a thousand cases and both be honest. If you need a number you can defend, go to the dockets.

The uncomfortable part for anyone reading this on a site about building your own software: small sites are targeted because they are small. They have more gaps, no in-house counsel, and a strong incentive to settle rather than litigate. Being unknown is not cover.

The four barriers that dominate the complaints

Complaints are not evenly spread across the guidelines. Four classes of barrier account for most of what gets cited, and all four are findable in an afternoon:

• Missing or empty alt text. Images that carry meaning with no text alternative — and decorative images not marked as decorative, which is the same bug facing the other way. (WCAG 1.1.1)
• Form controls with no label. An input whose only label is placeholder text, or a visual label never programmatically tied to its field, so a screen reader announces "edit text" and nothing else. (WCAG 3.3.2, 4.1.2)
• Keyboard-inoperable controls and invisible focus. A <div> with a click handler and no keyboard path, or a focus ring removed in CSS because it looked untidy. (WCAG 2.1.1, 2.4.7)
• Insufficient contrast. Gray-on-gray body text, and low-contrast control boundaries. (WCAG 1.4.3, 1.4.11)

AI-generated front-ends produce all four freely, and for a consistent reason: a model optimizes the markup it was asked for, and nobody asks for a label they cannot see. Placeholder-only inputs, outline: none, and clickable divs are house style in generated code.

Finding them is not the hard part. Layout problems in AI front-ends and the 15-minute pre-launch review both cover the mechanics. The hard part is what you say about the result.

Overlay widgets do not protect you

The overlay business model is one line of JavaScript that promises to resolve the problem for a monthly fee. The pitch is aimed precisely at the anxiety this article opened with, and the evidence against it is not subtle:

• In January 2025, the Federal Trade Commission settled with the overlay vendor accessiBe for $1,000,000, over how the company had advertised what its plug-in did for a website. That is a published federal enforcement action, not a tracker estimate, and it is the one figure on this page you can read in the government's own words.
• Roughly 1,400 companies running an overlay widget were reported among 2025's defendants.
• 38.5% of businesses that got sued are reported to have had one installed when the suit arrived.

Those last two do not multiply together, and it is worth seeing why. 38.5% of 3,117 filings is about 1,200, not 1,400 — so the percentage and the headcount are not drawn over the same population. One of them is counting something wider than federal filings, or a different window, and the brief we took them from does not say which. We are printing both with the discrepancy visible rather than quietly dropping whichever one spoiled the arithmetic. Do not combine them.

What the two figures agree on is the direction, and it is the direction that matters: a widget on the page correlated with being sued rather than with being spared. The widget does not change the underlying document — the image still has no alt text, the div still cannot take focus — while adding a visible, script-detectable marker that a page is worth scanning.

What an accessibility statement is for

An accessibility statement is not a defense. It will not stop a demand letter and it is not a substitute for fixing anything. But it is the artifact a plaintiff's researcher looks for, and its absence gets cited — so the cheapest honest move available to you is to have one that is true.

A statement that does its job says four things, on the W3C WAI shape:

• The standard you are aiming at, named as a target you are working toward. For nearly everyone that is WCAG 2.1 Level AA.
• What you already know is wrong — the specific gaps, in specific words. This is the section people delete, and it is the section that makes the rest of the page believable.
• How to report a barrier: a real contact route, and by when you will answer. A contact address with no stated response time is a suggestion box.
• The date it was written and the date it was last reviewed. Both real.

What it must never say

Here is the part that gets sites into trouble, and it is worth being precise rather than gesturing at it. Conformance is a conclusion someone else reaches after testing your pages, usually with assistive technology and usually with a disabled tester in the room. It is not a status you can issue about yourself. So a statement must never:

• Declare conformance as already achieved. Any sentence whose subject is your site, whose verb is in the present tense, and whose object is the name of a law or a standard, is a claim you cannot support and someone else can disprove with one screenshot.
• Describe the site as accessible without qualification, to everyone, or in full. The word "fully" is doing no work in that sentence except raising the bar you have just failed to clear.
• Promise that any tool, plug-in, or audit has resolved it. No product confers a legal status. That is the exact class of representation the FTC action above was about.
• Cite an audit that does not exist, or dress an automated scan up as one. Automated checks catch a real but small fraction of the WCAG success criteria; the rest need a person. Saying "our automated checks are green" is true and useful. Letting a reader hear "audited" is neither.
• Make a promise with no date attached. "We are committed to accessibility" is not a commitment; it is a mood. "We reply to barrier reports within 5 business days" is a commitment, because you can fail it.

The general rule underneath all five: say what you measured, say what you did not, and never let the second list be empty.

A worked example, on this site

Rather than invent one, read ours: the accessibility statement for this site. It is written to the shape above and it does the uncomfortable parts.

• It opens with what we do not claim, before anything else — that no part of the site has been independently audited, and that nobody who depends on assistive technology has tested it for us.
• It names WCAG 2.1 Level AA as the target, in the language of aiming rather than arriving.
• It gives each of the four barrier classes above as a count over a denominator, measured the day it was written: images with no text alternative, form fields with no label, keyboard barriers, and text contrast. Every one of those lines then says what it left ungraded, which is the word that page uses for "nobody has looked."
• It publishes a live defect under our own name — the home page has no skip link — rather than waiting until the number is flattering.
• It gives an address and a stated 5 business day reply window, and real written and reviewed dates.
• It says we do not use an overlay, and why.

It is not a flattering page. That is the point: a statement that flatters you is a statement nobody can act on, including you.

Where every claim here comes from

The rule on this site is that a claim carries its source. Here is the whole ledger for this page, sorted by how much weight each source will bear.

• Government documents, public, and checkable by you: the ADA's 1990 date and the wording of Title III; the existence of a DOJ web rule under Title II, its adoption of WCAG 2.1 Level AA, and the fact that its compliance dates run to state and local government bodies; the absence of any parallel Title III technical rule for private business, and the 2017 withdrawal of the rulemaking aimed at one. All of it is published by the Department of Justice at ada.gov. We are pointing you at the source rather than asking you to take our summary of it.
• The W3C, also public: WCAG 2.1 Level AA and every success criterion number named beside the four barrier classes, at w3.org/WAI; the four-part shape of a statement, at the W3C WAI statement guidance.
• A published federal enforcement action: the Federal Trade Commission's January 2025 settlement with accessiBe, and the $1,000,000 figure, at ftc.gov. This is the only figure on the page that comes from the body that imposed it.
• Private litigation trackers, taken second-hand, not audited by us: 3,117 filings, the 27% year-on-year rise, the 35,000–50,000 demand-letter estimate, the $5,000–$75,000 settlement range, roughly 1,400 overlay-running defendants, the 38.5% figure, and the ranking of the four barrier classes by how often they are cited. These come from a research brief compiled for this project on September 12, 2026, drawing on the annual counts that accessibility vendors and defense-side firms publish. We did not open a docket to verify any of them, and we are not attaching a citation we do not hold. The discrepancy we flagged between the 38.5% and the 1,400 is the visible edge of exactly that limitation.
• Measured in this project: the claim that our own build refuses assertive compliance wording is not rhetoric. The deploy build scans every published page against a fixed list of 25 assertive phrases and stops the build when one appears — so the first item under "What it must never say" is enforced here rather than merely intended. The other four are not, and the guard's own documentation enumerates six shapes it cannot catch, including one grammatical form that has no safe version at all. A green build on this site is a guard against the commonest sentence, not an audit, and not a substitute for reading your own copy.
• Not a source for anything: this article. It is a summary written for builders, not a legal determination, and it does not become one by being specific.

Next: A security checklist for AI-generated code →