ADA Title III is the part of the Americans with Disabilities Act that covers public accommodations — private businesses and nonprofits that are open to the public. It is often discussed together with website accessibility, but Title III is not a WCAG checklist and it is not the same rule as the Department of Justice’s 2024 Title II web and mobile regulation for state and local governments.
This article explains what Title III covers, how courts and agencies have treated websites, where WCAG fits as a technical benchmark, and what businesses should actually test. It is technical accessibility guidance, not legal advice.
What is ADA Title III?
Title III prohibits discrimination on the basis of disability in places of public accommodation. Typical examples include restaurants, hotels, medical offices, retail stores, banks, and many other businesses that serve the public.
The statute and the 2010 ADA Standards for Accessible Design address physical facilities in detail. They do not set a numbered WCAG version as the Title III rule for every private website. That gap is why website cases have been argued in courts rather than decided by a single Title III web regulation.
Which businesses are public accommodations?
Title III lists categories of public accommodations. A business can be covered because of what it offers, not because it is large. Size, revenue, or “having a website” is not by itself the legal test.
Whether a particular organization is a public accommodation, and whether a particular digital property is covered, depends on facts and applicable law. That determination is legal analysis. An accessibility audit can document barriers in an interface; it cannot declare that a company is or is not covered by Title III.
How does Title III relate to websites?
Many Title III lawsuits involving websites argue that a site is a service of a public accommodation, or that it is itself a place of public accommodation. Outcomes have varied by court and by facts — for example, whether the business also has a physical location, and how the website is used to offer goods or services.
It is not accurate to say that every publicly available digital service in the United States automatically “falls under Title III” in the same way, or that Title III “ensures” websites are legally compliant. Courts decide cases. An inaccessible website can still create real barriers for people with disabilities and real legal risk for some businesses. Those are related issues, not the same sentence.
Does DOJ require WCAG 2.1 AA for every private website?
No. In April 2024 the Department of Justice issued a final rule for state and local government web content and mobile apps under ADA Title II. That rule uses WCAG 2.1 Level A and Level AA as the technical standard, with the rule’s own scope, exceptions, and compliance dates.
That Title II rule does not, by itself, impose the same WCAG 2.1 AA requirement on every private Title III website. Treating the 2024 Title II rule as if it already bound all private businesses is a common source of inaccurate marketing copy.
DOJ has also brought Title III enforcement involving websites in specific matters. Those actions are not a substitute for a generally applicable Title III web regulation that names WCAG for all private sites.
Title III vs Title II
- Title II — state and local governments. The 2024 DOJ web and mobile rule applies here and names WCAG 2.1 A/AA for covered web content and mobile apps, subject to the rule.
- Title III — private public accommodations. No equivalent generally applicable DOJ web rule currently names WCAG for all private websites.
If you operate a government site, plan against the Title II rule and its dates. If you operate a private business site, Title III and court decisions may still be relevant — but the technical target you choose (for example WCAG 2.2 AA) should be stated as an accessibility target, not as “the Title III legal standard for every website.”
Why WCAG is used as a technical benchmark
WCAG is the most widely cited technical standard for web accessibility. Settlement agreements, procurement language, and expert testimony often use WCAG success criteria because they are testable: contrast, names, keyboard access, form labels, and so on.
Using WCAG 2.1 AA or WCAG 2.2 AA as an audit target is a practical way to evaluate barriers. It is not the same as a court finding, a DOJ determination, or a guarantee of legal compliance.
What businesses should test
Regardless of legal theory, these are the places where people actually get stuck. They also map cleanly onto WCAG success criteria you can use as an audit benchmark:
- Primary navigation and search — skip links, menus, landmarks, and whether search results can be reached from the keyboard.
- Forms, including validation and error recovery — visible labels, instructions, error text that names the field, and a path to correct the mistake. See also why accessible forms still fail.
- Checkout, booking, and account creation — multi-step flows, timeouts, payment iframes, and confirmation pages.
- Keyboard access and visible focus — every action available without a pointer, in a sensible order, with a focus indicator that can be seen.
- Screen-reader names, roles, and states — buttons that are not unnamed, expand/collapse that announces, and live errors that can be found.
- PDFs and downloadable documents that carry essential information — tags, reading order, and whether the same content exists in HTML.
- Third-party widgets — chat, payments, cookie banners, maps, and video players. A passing homepage does not mean the widget is usable.
Automated scanners catch some of these issues in HTML. They do not complete a keyboard pass, a screen-reader pass, or a journey through checkout.
Automated vs manual evaluation
Use automated tools to find repeated code-level failures. Use manual evaluation to confirm whether a person can complete the task. For a detailed comparison, see automated vs manual accessibility testing.
What to do after finding barriers
- Record the barrier, the affected user group, and the WCAG criterion you used as a benchmark.
- Fix shared components first (header, forms, buttons) so the same defect does not reappear on every page.
- Retest the journey, not only the component in isolation.
- Keep a dated inventory. Accessibility work is incomplete if findings are never rechecked.
A manual WCAG audit is the usual next step when you need a prioritized report rather than another scan export.
Technical accessibility disclaimer
ADA Access Group provides technical accessibility testing and remediation support. This article summarizes publicly available legal structure for context. It is not legal advice, and it does not determine whether any organization is covered by the ADA.