ADA website accessibility: what the law requires, what testers look for, and what an overlay will not fix
If you run a public-facing website in the United States, you have probably been told it is not ADA compliant, most likely by a company selling a widget that promises to make it so. The pressure is real, the letters are real, and the widget is mostly not the answer. What follows is the shape of the actual obligation, what a demand letter is typically assembled from, and the work that changes your position rather than your invoice. None of it is legal advice, and if a letter is already on your desk, your first call belongs to an attorney rather than to a developer.
There is no ADA web standard for private businesses, and that is why the letters keep coming
The Americans with Disabilities Act predates the commercial web and contains no technical specification for websites. The Department of Justice's guidance on web accessibility takes the position that Title III applies to the websites of businesses open to the public, while explicitly saying businesses have flexibility in how they provide access. Flexibility sounds generous until you realize it means there is no certificate, no safe harbor and no box to tick.
Two adjacent rules get quoted at business owners and do not apply to them. The DOJ's 2024 rule adopting WCAG 2.1 Level AA covers web content and mobile apps of state and local government entities under Title II, not private companies. Section 508 covers federal agencies and, in practice, the vendors selling to them. If you sell to a public university or a federal agency, that becomes a contract requirement and you will see it in the RFP. Otherwise, what fills the vacuum is the standard courts and settlement agreements keep reaching for anyway: the W3C's Web Content Accessibility Guidelines, generally 2.1 at Level AA.
What a demand letter is usually built from
Most letters do not follow a careful manual audit. They follow an automated scan of a handful of pages, and the findings repeat across industries because the failures repeat across templates. Knowing the list is useful, because it is also the list of things worth fixing first.
The federal claim is frequently paired with a state one. California's Unruh Civil Rights Act attaches statutory damages to a violation, which is a large part of why filings concentrate where they do, and New York statutes serve a similar role. That pairing is what turns an accessibility defect into a settlement calculation, and it is also why fixing the site is cheaper than arguing about whether the ADA reaches it.
- Images carrying meaning with no alternative text, and decorative images that are not hidden from assistive tech
- Form inputs with placeholder text instead of a real label, and errors announced only by color
- Text and buttons that fail contrast requirements, usually grey-on-white body copy
- Navigation and dropdowns that cannot be reached or opened with a keyboard alone
- No visible focus indicator, so a keyboard user cannot tell where they are
- Modals and cookie banners that trap focus or cannot be dismissed without a mouse
- Video without captions, and PDFs published as scanned images with no HTML equivalent
Why overlay widgets do not end the problem
An overlay is a script that loads after your page and tries to patch it in the browser: guessing at alt text, adjusting contrast, and offering a toolbar of profiles. The pitch is that one line of code produces compliance. The reason it does not is structural. The widget cannot know what your image means, cannot restructure a heading order, cannot label a field whose purpose is ambiguous, and cannot fix a component that was never keyboard operable. It sits on top of the same markup.
There is also the small matter of who it is for. Screen reader users have publicly and repeatedly objected to overlays, including cases where the widget interferes with the assistive technology the person already uses and trusts. And plaintiffs have continued to file against businesses that had an overlay installed, which tells you what protective value the subscription carries in practice. The W3C is explicit that automated tools cannot determine conformance on their own, because a large share of the success criteria require human judgment about meaning and context. A product built entirely on automation inherits that limit.
The work that actually changes your position
Real remediation is unglamorous and mostly happens in the markup. Semantic HTML gets you a surprising distance: a real button element is keyboard operable and announced correctly without anyone writing a line of JavaScript to make it so. From there it is labels, contrast, focus management, and a policy your content editors can follow so the site does not regress the week after it is fixed.
The cheapest version of this is to build it in rather than bolt it on. Accessibility added during design and development costs a fraction of accessibility retrofitted into a finished theme, and it produces a better site for everyone: clearer labels, readable contrast, forms that explain their own errors. If you are already planning a redesign, that is the moment to do it, not a separate project afterwards.
- Semantic markup and a sensible heading order on every template, not just the homepage
- Every input visibly labeled, with errors described in text and tied to the field
- Color contrast checked for body text, buttons, placeholders and states, not only headlines
- Full keyboard operability with a visible focus style, tested by unplugging the mouse
- Alt text rules written into the CMS so editors know what to do with each image
- Captions for video, and an HTML alternative for any PDF a customer needs
- Manual testing with a screen reader on the flows that matter: contact, booking, checkout
- An accessibility statement with a real contact channel and a response process behind it
What nobody can honestly promise you
No studio can guarantee you will not receive a demand letter, and no vendor can certify your site as ADA compliant, because there is no certifying authority to do it. Anyone selling that guarantee is selling a feeling. What is achievable is measurable conformance to a published standard, documented testing, and a remediation record that shows a good-faith process, which is a materially different conversation to be in if a claim arrives.
We will also tell you when the work is out of proportion. A brochure site with six pages is a contained job. A ten-year-old platform with a third-party booking iframe, a legacy PDF library and a checkout you do not control is not one project, it is a sequence, and the honest plan starts with the pages that carry your transactions rather than with a sitewide sweep you will abandon in month two.
Frequently asked questions
Does the ADA actually apply to my website?
The Department of Justice's guidance takes the position that Title III reaches the websites of businesses open to the public, and courts have largely allowed those claims to proceed, though reasoning varies by circuit. The practical answer for a US business with a public site is to plan as if it applies. Whether it applies to your specific business is a question for your attorney.
Which standard should we target?
WCAG 2.1 Level AA is the working reference. It is what the DOJ adopted for state and local government content, what settlement agreements typically name, and what testers evaluate against. WCAG 2.2 exists as a W3C recommendation and adds criteria worth knowing, but 2.1 AA is the level most US obligations are written around today.
We installed an accessibility widget. Are we covered?
No. The widget may improve a few surface issues, but it does not repair the underlying markup, and businesses running overlays have still been sued. Treat it as, at best, a temporary aid and, at worst, a subscription that delayed the real work. Do not present it to anyone as compliance.
Is an automated scan enough to know where we stand?
It is a starting inventory, not a verdict. Automated tools reliably catch missing alt attributes, contrast failures and unlabeled inputs. They cannot judge whether alt text is meaningful, whether a heading structure makes sense, or whether a custom component behaves correctly for a screen reader user. Those require a person testing the actual flows.
We just received a demand letter. What is the first move?
Contact an attorney before responding, before making public statements, and before signing anything a vendor puts in front of you. In parallel, preserve the current state of the site and start documenting remediation. The technical work matters, but the sequence and the record are legal decisions, not development ones.
If you want to know where your site actually stands, send us the URL and the flows that matter most: contact, booking, checkout. We will test them by keyboard and screen reader, tell you what is a template fix versus a rebuild, and quote the remediation in the order that reduces your exposure fastest. We do not sell overlays.