ADA Website Compliance for Small Businesses: A WCAG 2.2 AA Guide
A plain-English guide to ADA website compliance for US small businesses: Title III and websites, the DOJ Title II rule for governments, why demand letters happen, why overlays do not make a site compliant, a WCAG 2.2 AA checklist and what to put in an accessibility statement.

The Americans with Disabilities Act (ADA) does not contain a website-specific regulation for private businesses, but the Department of Justice has long taken the position that Title III covers the goods and services businesses offer online. As of September 2026, there is still no DOJ technical standard for private business websites, so in practice courts, settlements and DOJ itself point to the Web Content Accessibility Guidelines (WCAG). For a small business, the defensible approach is to make the website meet WCAG 2.2 Level AA, document the work, and publish an accessibility statement with a working contact route.
This guide explains where the law stands, why small businesses receive demand letters, why accessibility overlays are not a fix, and gives a practical audit checklist.
This article is general information, not legal advice. If you have received a demand letter or complaint, speak to a lawyer licensed in the relevant state.
How the ADA Applies to Websites
Title III and public accommodations
Title III of the ADA prohibits discrimination on the basis of disability by "places of public accommodation", a list of business categories that includes stores, restaurants, hotels, professional offices, banks and many others. The ADA was passed in 1990, before commercial websites existed, so it does not mention them.
The DOJ's guidance on web accessibility and the ADA, published in 2022, states that the Department has consistently taken the position that the ADA's requirements apply to all the goods, services, privileges or activities offered by public accommodations, including those offered on the web. The same guidance says businesses have flexibility in how they comply, but must still ensure their online offerings are accessible, and points to WCAG and the Section 508 Standards as helpful technical guidance.
Courts do not all agree on scope
Federal courts are split on one important question: whether a business that exists only online is a "place of public accommodation". Some circuits require a connection (a "nexus") between the website and a physical location. In Robles v. Domino's Pizza (9th Cir. 2019), for example, the court held the ADA applied to the website and app because they connected customers to Domino's physical restaurants. Other courts have taken broader or narrower views.
For a small business, this split matters less than it seems. Most small businesses that sell or book online also have a physical presence, and even where a claim might ultimately fail, defending it costs money. Some state laws also apply independently: California's Unruh Civil Rights Act, for instance, allows statutory damages for ADA violations, which is one reason many claims are filed there.
DOJ Rules: Governments Versus Private Businesses
The Title II rule for state and local governments
In April 2024, DOJ published a final rule under Title II (state and local governments) adopting WCAG 2.1 Level AA as the technical standard for web content and mobile apps. On 20 April 2026, DOJ issued an interim final rule extending the compliance dates by one year:
| Public entity | Original compliance date | Extended compliance date |
|---|---|---|
| Population of 50,000 or more | 24 April 2026 | 26 April 2027 |
| Population under 50,000, and special district governments | 26 April 2027 | 26 April 2028 |
The technical standard, WCAG 2.1 Level AA, did not change. This rule applies to government entities, not private businesses. It does matter to private firms in two ways: vendors that build or run websites and apps for governments will be expected to deliver WCAG 2.1 AA, and the rule shows which standard DOJ considers appropriate.
No specific regulation for private businesses
There is no equivalent Title III regulation. DOJ began rulemaking for public accommodations years ago and withdrew it in 2017, and as of September 2026 no Title III web rule has been adopted. That does not mean private websites are exempt: the general nondiscrimination and effective communication obligations still apply, DOJ settlements have referenced WCAG, and private plaintiffs continue to bring claims. It means the standard is set by guidance, settlements and case law rather than a regulation with a safe-harbour deadline.
Why Small Businesses Receive Demand Letters
Title III lets private plaintiffs seek injunctive relief (an order to fix the site) and recover attorneys' fees. Federal law does not provide damages to private Title III plaintiffs, but state laws like California's may. The combination makes it economical to send demand letters in volume.
Common triggers are easy to detect with automated tools:
- images and product photos without alt text;
- form fields without labels;
- low colour contrast;
- links and buttons with no accessible name, such as icon-only buttons;
- menus, popups and checkout steps that cannot be used with a keyboard;
- PDF menus, price lists or forms that screen readers cannot read.
Because these issues are machine-detectable, a site can be flagged without anyone attempting to buy from it. That is also why fixing the common failures significantly reduces exposure: it removes the easy targets.
If you receive a letter, do not ignore it, do not immediately install a widget and declare the problem solved, and do not admit or deny anything before taking advice. Preserve records of the site's state, commission an audit, and let your lawyer handle the response.
Why Accessibility Overlays Do Not Make a Site Compliant
Overlays are JavaScript widgets, often sold as a single line of code, that add a toolbar with options such as larger text or contrast modes and claim to repair accessibility automatically. They are widely marketed as a route to ADA compliance. They are not.
- Regulators have acted on the claims. In January 2025, the Federal Trade Commission announced an order requiring accessiBe to pay USD 1 million over claims that its AI-powered tool could make any website compliant with WCAG. The FTC approved the final order in April 2025. The FTC's complaint alleged the tool failed to make basic components such as menus, headings, tables and images compliant.
- Disabled users and accessibility professionals object. The Overlay Fact Sheet, signed by hundreds of accessibility practitioners and disabled users, explains that overlays can interfere with the assistive technology people already use and do not repair underlying code.
- Sites with overlays still receive complaints. Installing a widget does not stop a plaintiff from testing the underlying page, and the presence of an overlay is not a defence.
Screen reader users rely on their own software, configured for their needs. What they need is correct HTML: real headings, labelled controls, keyboard support, meaningful alt text. Those fixes live in the theme, templates and content. No script bolted on top can reliably provide them.
A WCAG 2.2 AA Audit and Fix Checklist
WCAG 2.2 is the current W3C Recommendation. It contains all of WCAG 2.1 (minus the obsolete 4.1.1 Parsing criterion) plus new criteria, so meeting 2.2 AA also meets the 2.1 AA standard DOJ adopted for governments. See the W3C's What's New in WCAG 2.2 for the additions.
Step 1: Choose the pages to test
Pick a representative sample rather than every URL: home page, main service or category pages, one example of each template (product, blog post, location page), contact and booking forms, cart and checkout, login, search results, and any PDF customers are expected to use.
Step 2: Run automated checks
Run axe DevTools, WAVE or Lighthouse on each page. Automated tools find a meaningful share of issues quickly but cannot judge quality or usability, so treat them as the first pass, not the audit.
Step 3: Test manually
| Check | How to test | WCAG reference |
|---|---|---|
| Keyboard access | Unplug the mouse. Tab through the page, open menus, use every form, complete a purchase or booking | 2.1.1, 2.1.2 |
| Visible focus | Can you always see where focus is? Is it hidden by sticky headers or chat bubbles? | 2.4.7, 2.4.11 |
| Headings and structure | Use a headings outline tool. One H1, logical order, no headings used only for styling | 1.3.1, 2.4.6 |
| Alt text | Informative images described; decorative images have empty alt | 1.1.1 |
| Colour contrast | 4.5:1 for normal text, 3:1 for large text and UI components | 1.4.3, 1.4.11 |
| Colour alone | Errors, required fields, links and status not signalled only by colour | 1.4.1 |
| Form labels | Every input has a visible label tied to it in code; placeholders are not labels | 1.3.1, 3.3.2 |
| Error messages | Errors described in text, next to the field, with a suggested fix | 3.3.1, 3.3.3 |
| Link and button names | "Read more" and icon buttons have accessible names that make sense out of context | 2.4.4, 4.1.2 |
| Zoom and reflow | Page works at 200% zoom and at 320 CSS pixels wide without horizontal scrolling | 1.4.4, 1.4.10 |
| Media | Videos captioned; audio has transcripts; no autoplay audio | 1.2.2, 1.4.2 |
| Target size | Buttons and links at least 24 by 24 CSS pixels or adequately spaced | 2.5.8 |
| Dragging | Sliders and drag interactions have a click or input alternative | 2.5.7 |
| Consistent help | Contact or help link in the same place on every page | 3.2.6 |
| Redundant entry | Customers are not asked to re-enter information already given in the same process | 3.3.7 |
| Authentication | Password managers and paste work; no puzzle-only CAPTCHA | 3.3.8 |
Step 4: Screen reader spot-check
Test the key journeys with at least one screen reader: VoiceOver on macOS or iOS, or NVDA on Windows (free). Listen for unlabelled buttons, focus jumping unexpectedly, and modal dialogs that trap or lose the user.
Step 5: Fix in the right place
- Theme and templates: fix heading structure, focus styles, skip links, menus and colour tokens once, and every page benefits.
- Plugins and apps: sliders, popups, booking widgets, review widgets and chat tools are frequent sources of failures. Replace components that cannot be fixed.
- Content: alt text, link text, captions and PDFs are editorial work. Train whoever publishes content, and add accessibility fields to your publishing checklist.
- Documents: convert important PDFs to HTML pages where possible. Accessible HTML is easier to maintain than tagged PDFs.
Step 6: Keep it fixed
Accessibility regresses when new plugins, campaign landing pages and theme updates ship. Add an accessibility check to your website maintenance routine, and if you are planning a redesign, write WCAG 2.2 AA into the brief from day one; the website redesign guide covers how to protect existing SEO and leads during that process.
What to Put in an Accessibility Statement
An accessibility statement is not legally required for private US businesses, but it shows good faith, gives users a way to report problems before they become complaints, and forces you to be specific about what you have done. The W3C's guidance on developing an accessibility statement includes a generator. Include:
- 1Commitment and target: "We aim to meet WCAG 2.2 Level AA."
- 2Current status: partially or fully conformant, and the date of your last review.
- 3Known limitations: named third-party components or content that do not yet meet the standard, and planned fixes.
- 4How you test: internal checks, external audit, user testing.
- 5Feedback route: an email address and phone number monitored by a real person, with an expected response time.
- 6Alternative access: how customers can order, book or get information by another route if part of the site is not usable for them.
Avoid claims you cannot support, such as "fully ADA compliant" or "certified accessible". There is no official ADA website certification, and an inaccurate claim can be used against you.
Accessibility as Part of a Better Website
Accessibility work overlaps heavily with good usability and SEO: clear headings, descriptive links, labelled forms and fast, robust templates help every visitor and search engines too. Service businesses that depend on enquiries benefit directly, because an inaccessible contact or booking form loses leads as well as creating legal risk; the lead generation website guide covers form design in more depth.
Getting Help
ADA website risk is real but manageable: fix the common failures, audit against WCAG 2.2 AA, avoid overlay shortcuts and publish an honest accessibility statement. If you want an audit and remediation plan for a WordPress, WooCommerce, Shopify or Next.js site, see our website development services or contact us to discuss your site.
Related posts

E-commerce Requirements Workshop: Discovery and Approval
Turn stakeholder assumptions into an approved e-commerce brief using sample orders, decision logs and testable acceptance criteria.
Read article →

European Accessibility Act for E-Commerce Websites: What Stores Must Do
A practical guide to the European Accessibility Act (Directive (EU) 2019/882) for e-commerce and consumer service websites: who is in scope, the microenterprise exemption, EN 301 549 and WCAG, accessibility information, enforcement and a remediation plan for WooCommerce and Shopify stores.
Read article →

Google Consent Mode v2 and Cookie Consent: A Setup Guide for Business Sites
How to set up Google Consent Mode v2 alongside a compliant cookie banner: ePrivacy and PECR consent rules, the GDPR consent standard, the four consent parameters, basic versus advanced mode, CMP requirements, WordPress and Shopify implementation, Tag Assistant testing and common mistakes.
Read article →
Author
Anushka Dahanayake
Anushka Dahanayake builds SEO-focused websites, e-commerce platforms, dashboards, and automation systems for businesses worldwide.
