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.

ADA Website Compliance for Small Businesses: A WCAG 2.2 AA Guide article cover image

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 entityOriginal compliance dateExtended compliance date
Population of 50,000 or more24 April 202626 April 2027
Population under 50,000, and special district governments26 April 202726 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

CheckHow to testWCAG reference
Keyboard accessUnplug the mouse. Tab through the page, open menus, use every form, complete a purchase or booking2.1.1, 2.1.2
Visible focusCan you always see where focus is? Is it hidden by sticky headers or chat bubbles?2.4.7, 2.4.11
Headings and structureUse a headings outline tool. One H1, logical order, no headings used only for styling1.3.1, 2.4.6
Alt textInformative images described; decorative images have empty alt1.1.1
Colour contrast4.5:1 for normal text, 3:1 for large text and UI components1.4.3, 1.4.11
Colour aloneErrors, required fields, links and status not signalled only by colour1.4.1
Form labelsEvery input has a visible label tied to it in code; placeholders are not labels1.3.1, 3.3.2
Error messagesErrors described in text, next to the field, with a suggested fix3.3.1, 3.3.3
Link and button names"Read more" and icon buttons have accessible names that make sense out of context2.4.4, 4.1.2
Zoom and reflowPage works at 200% zoom and at 320 CSS pixels wide without horizontal scrolling1.4.4, 1.4.10
MediaVideos captioned; audio has transcripts; no autoplay audio1.2.2, 1.4.2
Target sizeButtons and links at least 24 by 24 CSS pixels or adequately spaced2.5.8
DraggingSliders and drag interactions have a click or input alternative2.5.7
Consistent helpContact or help link in the same place on every page3.2.6
Redundant entryCustomers are not asked to re-enter information already given in the same process3.3.7
AuthenticationPassword managers and paste work; no puzzle-only CAPTCHA3.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:

  1. 1Commitment and target: "We aim to meet WCAG 2.2 Level AA."
  2. 2Current status: partially or fully conformant, and the date of your last review.
  3. 3Known limitations: named third-party components or content that do not yet meet the standard, and planned fixes.
  4. 4How you test: internal checks, external audit, user testing.
  5. 5Feedback route: an email address and phone number monitored by a real person, with an expected response time.
  6. 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

European Accessibility Act for E-Commerce Websites: What Stores Must Do article cover image
Compliance & Accessibility••12 min read

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 article cover image
Compliance & Accessibility••10 min read

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.