ADA Website Compliance: A Practical Guide for Businesses

If you run a website for a US business, you’ve probably heard that it needs to be “ADA compliant.” The Americans with Disabilities Act doesn’t mention websites by name — it predates the modern web — but courts and the Department of Justice have repeatedly treated websites as covered, and the practical standard everyone uses is WCAG 2.1/2.2 Level AA. Here’s what that means for you, without the legal jargon.

This article is general information, not legal advice. For how a specific obligation applies to your organization, consult a qualified attorney — and see our accessibility disclaimer.

Why ADA web lawsuits keep rising

Web-accessibility lawsuits and demand letters have grown year over year, largely because the barrier to filing is low and the defects are easy to demonstrate. A plaintiff (often using a screen reader) only needs to show they couldn’t complete a basic task — read a menu, add an item to a cart, submit a form. Most cases settle, which makes serial filing economically attractive. The result: thousands of businesses, large and small, receive demand letters every year.

Who is covered

• Title III — “places of public accommodation,” which courts have widely applied to commercial websites (retail, hospitality, finance, healthcare, and more).
• Title II — state and local government. In 2024 the DOJ issued a rule formally adopting WCAG 2.1 AA for Title II entities, with compliance deadlines phased by population size.
• Section 508 — federal agencies and many of their contractors; also keys to WCAG AA.

Even where your specific obligation is debatable, the cost of a baseline of accessibility is far lower than the cost of defending a claim — and it’s simply better product.

What “compliant” looks like in practice

There is no government “ADA certificate” for websites. Compliance means your site meets WCAG AA and you can show a good-faith, ongoing effort. Concretely:

• Keyboard users can reach and operate everything; focus is always visible.
• Screen readers get meaningful names for images, buttons, links, and form fields.
• Color contrast meets AA, and color is never the only signal.
• Forms have labels and clear, text-based error messages.
• Content reflows and remains usable at high zoom and on mobile.
• You have an accessibility statement and a way for users to report problems.

A pragmatic path to lower risk

1. Baseline scan — run an automated scan across your highest-traffic and highest-stakes pages (home, key landing pages, search, cart, checkout, contact) to get a prioritized list of defects.
2. Fix Critical and Serious first — these are the issues that actually block tasks and show up in demand letters.
3. Add manual testing — automated tools catch a large share of issues but not all; test key flows with a keyboard and a screen reader. See our methodology for where automation stops.
4. Publish an accessibility statement — state your target (WCAG 2.2 AA), how to contact you, and that you’re continuously improving.
5. Re-test on every release — accessibility regresses; make scanning part of your normal QA.

A warning about “accessibility overlays”

Overlay widgets that promise instant compliance with one line of JavaScript are widely criticized by the accessibility community and have themselves been the subject of lawsuits. They don’t fix the underlying code and can interfere with the assistive technology users already rely on. There’s no shortcut — the durable fix is accessible markup.

Start with a clear picture

You can’t prioritize what you can’t see. The first step is an honest, scored inventory of where your site stands today — which defects exist, how severe they are, and how widespread. From there the remediation work becomes a finite, rankable list rather than a vague fear. Questions before you start? Our FAQ covers the common ones.