ADA Website Compliance for Small Businesses: A Practical WCAG 2.2 Checklist

Does the ADA apply to business websites?

Yes, according to the federal agency that enforces it. Title III of the Americans with Disabilities Act covers businesses open to the public, such as stores, restaurants, medical offices, hotels and service companies. The Department of Justice states in its web guidance that these businesses must make their websites accessible to people with disabilities, and it has said so consistently.

What the DOJ has not done is publish a technical rule for private businesses that names a specific standard. That gap is why the topic feels confusing. In practice, courts, settlements and the DOJ itself point to the Web Content Accessibility Guidelines, known as WCAG, as the measure of an accessible site.

Federal courts have not all agreed on whether a website with no connection to a physical location is covered. Businesses with a physical store or office have the clearest exposure, but online-only businesses are sued too. The safe assumption for any US company that sells to the public is that its website should meet WCAG.

What about the 2024 DOJ rule?

In April 2024 the Department of Justice published a final rule under Title II of the ADA. It covers state and local governments, not private businesses, and it adopts WCAG 2.1 level AA as the required standard for their websites and mobile apps.

In April 2026 the DOJ issued an interim final rule extending the compliance dates. Public entities with a total population of 50,000 or more now have until April 26, 2027, and smaller entities and special district governments until April 26, 2028.

The rule matters to private businesses in two ways. It shows the standard the federal government considers appropriate. And if you build websites, sell software or provide content to cities, counties, school districts or public universities, your customers now need what you deliver to meet WCAG 2.1 AA.

What is WCAG, and which version should you use?

WCAG is a set of testable requirements published by the World Wide Web Consortium. Each requirement, called a success criterion, has a number, a level and a plain test. They are grouped under four principles: content must be perceivable, operable, understandable and robust.

There are three levels. Level A covers the most basic barriers, level AA the problems that affect many users, and level AAA a stricter set that few sites meet in full. Level AA is the standard referenced in lawsuits, settlements and government rules.

WCAG 2.2, published in October 2023, is the current version. It includes everything in 2.1 except one criterion it removed, and adds nine new ones. Building to WCAG 2.2 AA therefore satisfies 2.1 AA as well. New sites should target 2.2.

• Perceivable: people can see or hear the content, or get it another way.
• Operable: people can use the site with a keyboard, a switch or voice, not only a mouse.
• Understandable: text, forms and navigation behave predictably and explain errors.
• Robust: the code works with assistive technology such as screen readers.

Which problems cause most accessibility complaints?

Website accessibility complaints rarely involve obscure technicalities. They describe a customer who could not complete an ordinary task, such as reading a menu, booking an appointment or paying for an order. The same problems appear again and again.

• Images without text alternatives, so screen reader users hear a file name or nothing at all.
• Low color contrast, such as light gray text on white, which many people cannot read.
• Keyboard traps and unreachable controls, where menus, sliders or pop-ups cannot be used without a mouse.
• Unlabeled form fields, so a screen reader announces an empty box instead of First name or Email.
• Video without captions and audio without transcripts.
• Menus, price lists and forms published as PDFs or images, which screen readers often cannot read.
• Checkout and booking widgets from third parties that fail the same tests as the rest of the site.

What does a WCAG 2.2 AA checklist include?

The full standard is long, but a small business site is usually judged on a core set of criteria. Here is the practical version, with the WCAG numbers so you or your developer can look up the exact requirement.

• Text alternatives (1.1.1): every meaningful image has alt text that says what it shows or does. Decorative images are marked so screen readers skip them.
• Captions (1.2.2): prerecorded video with sound has accurate captions, not unedited automatic ones.
• Structure (1.3.1): headings, lists and tables are marked up as such, not just styled to look like them.
• Contrast (1.4.3): normal text has a contrast ratio of at least 4.5 to 1 against its background, and large text at least 3 to 1.
• Zoom and reflow (1.4.4 and 1.4.10): text can be enlarged to 200 percent, and the page works at a width of 320 CSS pixels without sideways scrolling.
• Keyboard (2.1.1 and 2.1.2): every link, button, menu and form works with the keyboard alone, and focus never gets stuck.
• Visible focus (2.4.7 and 2.4.11): you can always see which element has keyboard focus, and it is not hidden behind a sticky header or cookie banner.
• Page titles and link text (2.4.2 and 2.4.4): each page has a descriptive title, and links make sense out of context, not Click here.
• Target size (2.5.8): buttons and links are at least 24 by 24 CSS pixels, or spaced so they are easy to hit.
• Language (3.1.1): the page declares its language, so screen readers pronounce it correctly.
• Forms (3.3.1 and 3.3.2): every field has a visible label, and errors are described in text, not only by turning a border red.
• Logins (3.3.8): signing in does not depend on solving a puzzle or memorizing something without an accessible alternative, such as allowing password managers and copy and paste.
• Code (4.1.2): custom controls expose their name, role and state to assistive technology.

What changed in WCAG 2.2?

WCAG 2.2 added criteria aimed mainly at people with low vision, motor disabilities and cognitive disabilities, and at mobile use. Six of the nine additions apply at level A or AA, so they matter for compliance.

Focus Not Obscured requires that the element with keyboard focus is not completely hidden by other content, a common failure on sites with sticky headers, chat buttons and cookie banners. Dragging Movements requires an alternative to drag-and-drop, such as buttons. Target Size requires controls of at least 24 by 24 CSS pixels or enough spacing around them. Consistent Help requires help options, such as a contact link or chat, to appear in the same place on each page. Redundant Entry says users should not have to type the same information twice in one process, such as a shipping and billing address. Accessible Authentication limits login methods that depend on memory or puzzles.

The version also removed criterion 4.1.1, Parsing, because modern browsers and assistive technology no longer depend on it.

How can you test your own website in 15 minutes?

You do not need special training to find the most serious problems. The W3C's Easy Checks guide describes a first review anyone can do. Here is a short version we suggest to business owners before they talk to any developer.

• Minutes 1 to 3: run your home page through WebAIM's free WAVE tool or the accessibility audit in Chrome's Lighthouse. Note the errors, especially missing alt text, empty links and contrast failures.
• Minutes 4 to 8: put the mouse away. Press Tab repeatedly from the top of the page. Can you see where you are each time? Can you open the menu, reach every link and submit your contact form with Enter and the arrow keys?
• Minutes 9 to 11: zoom the browser to 200 percent. Does the text still fit, or does it overlap and disappear?
• Minutes 12 to 15: turn on a screen reader, VoiceOver on a Mac or iPhone or the free NVDA on Windows, and listen to your contact form. Does each field announce its purpose?

Are accessibility overlays a shortcut to compliance?

No. Overlays are scripts, usually sold as a monthly subscription, that add a toolbar to a website and promise to fix accessibility automatically. They cannot repair problems in the underlying code, such as a checkout that cannot be operated with a keyboard, and disability advocates have criticized them for getting in the way of the assistive technology people already use.

Regulators have taken note. In April 2025 the Federal Trade Commission approved a final order requiring the overlay company accessiBe to pay $1 million. The FTC alleged the company misrepresented that its AI-powered tool could make any website compliant with WCAG, and also formatted paid reviews to look independent. The order bars such claims without evidence to support them.

Businesses using overlays have continued to be sued. The dependable route is to fix the site itself. An overlay may offer users a few display preferences, but it should never be treated as your compliance plan.

Do state laws add more risk?

Yes, in some states. California's Unruh Civil Rights Act treats an ADA violation as a violation of state law and allows statutory damages of at least $4,000 for each one, without requiring proof of actual financial loss. That has made California a frequent venue for accessibility claims.

New York's federal courts have also received a large share of website accessibility lawsuits, and claims there often cite the New York State and New York City human rights laws alongside the ADA. Our pages on web design for New York City and web design for Los Angeles describe how these local rules affect a website project.

Selling to the federal government brings a separate requirement. Section 508 of the Rehabilitation Act requires federal agencies to buy and use accessible technology, so vendors are asked to document how their products conform, often in an Accessibility Conformance Report.

What does fixing a real small business site look like?

Take an illustrative case: a family restaurant in Phoenix with a seven-year-old website. The restaurant is invented for this example, but the problems are the ones we see most often.

The 15-minute test finds that the menu is a scanned PDF, the hero slider cannot be paused or used with a keyboard, the reservation button is light gray text on a cream background, the photos have no alt text and the contact form uses placeholder text instead of labels.

The fix takes a few weeks, not a rebuild. The menu becomes an ordinary web page with headings and prices, which also lets Google read it. The slider is replaced by a single image with a clear headline. Button colors are adjusted to pass 4.5 to 1. Photos get short descriptions. Form fields get visible labels and error messages in text. The reservation widget is checked, and the restaurant asks its provider about known issues. Finally, an accessibility statement is added to the footer with a phone number and email address for anyone who has trouble.

The restaurant now has a site more people can use, a menu that search engines can read and a documented record of the work. None of that guarantees it will never receive a demand letter, but it puts the business in a far stronger position.

What should an accessibility statement say?

An accessibility statement is a short page that explains your commitment, the standard you aim for, known limitations and how to get help. It is not a legal shield, but it shows good faith and gives customers a way to reach you before they reach a lawyer.

• The standard you work toward, such as WCAG 2.2 level AA.
• The date of your most recent review.
• Known issues you are working on, such as an older PDF or a third-party widget.
• A phone number and email address for people who need help or another format.
• A promise to respond within a stated number of business days, and then keeping it.

How do you keep a site accessible after launch?

Accessibility is not a one-time project. Every new blog post, product photo, PDF or marketing pop-up can introduce new problems. Most sites that pass an audit at launch slowly drift out of compliance as content is added by people who were never told what to check.

Build it into routine work. Give everyone who publishes content a one-page checklist covering alt text, headings, link wording and captions. Run an automated scan monthly. Repeat the keyboard and screen reader test before each redesign or major feature. When choosing plugins, booking tools and payment widgets, ask the vendor for its accessibility documentation.

Accessibility also overlaps with good business. Clear labels, readable contrast and pages that work on small screens make forms easier for everyone to complete, which is why our conversion rate optimization work treats accessibility problems as conversion problems, and why accessible, well-structured pages tend to be easier for search engines to understand.

Where should you start?

Run the 15-minute test on your three most important pages this week and write down what fails. If the list is short, your developer can fix it directly. If the site is old, built on a heavy page builder or full of PDFs, a website redesign built to WCAG 2.2 AA from the start is often cheaper than patching.

Our web design team for US businesses builds and tests to WCAG 2.2 AA with automated tools, a keyboard and a screen reader, and online stores get the same treatment through our ecommerce and Shopify development work. If you are considering an outside team for the job, our guide on how to hire an offshore web development company explains what to ask before you sign.