ADA website accessibility for a small business.

The short answer

The Americans with Disabilities Act was passed in 1990 and does not mention websites. Title III of the Act bars discrimination by businesses open to the public, which the law calls public accommodations: shops, restaurants, clinics, hotels, gyms, law offices and most other places that serve customers.

In March 2022 the Justice Department published guidance saying that Title III covers the goods and services these businesses offer on the web, and that an inaccessible website can shut people out as surely as steps at an entrance. Its ADA pages also say that almost all businesses serving the public must follow the ADA, whatever their size. There is no exemption for a three-person firm.

What the law does not give you is a checklist. No regulation sets a technical standard for business websites. The practical benchmark is WCAG 2.1 level AA: it is the standard demand letters usually cite, and it is what the Justice Department chose in 2024 for the websites of state and local governments.

So the work is to make your site usable by people who cannot see the screen, cannot use a mouse, cannot hear a video or need larger text. Start where customers book, buy or get in touch, because a barrier there costs you the customer as well as the risk of a claim.

What US law says, and what it leaves open

Three points are settled enough to plan around:

• Title III applies to businesses open to the public, and the Justice Department reads it as covering their websites.
• There is no Title III regulation for websites. The 2022 guidance calls WCAG and the federal Section 508 standards helpful guidance, and leaves businesses free to choose how they comply.
• The only federal web rule with a technical standard covers state and local governments. It was adopted in April 2024 and uses WCAG 2.1 AA. In April 2026 the Justice Department moved its deadlines back by a year, to April 2027 for larger public bodies and April 2028 for smaller ones.

What is not settled is whether a business that exists only online is covered. In Robles v. Domino's, decided in January 2019, the federal appeals court for the Ninth Circuit held that the ADA applied to the Domino's website and app because they connect customers to its restaurants. The Supreme Court declined to hear the case that October. Courts in other parts of the country disagree about businesses with no physical location: some have allowed claims against them and others have thrown them out.

State laws add another layer. A private plaintiff who wins under federal Title III gets a court order to fix the barriers and their legal fees, not damages. Some state laws, such as California's Unruh Civil Rights Act, add money damages, so a letter may cite both. Which laws apply to your business depends on where you are and where your customers are, and that is a question for a lawyer.

If you also sell to consumers in the EU, the European Accessibility Act has rules of its own, with a written standard and an exemption for the smallest service businesses.

What a demand letter is, and what it is not

A demand letter comes from a law firm, usually on behalf of a named person who says they tried to use your website with a screen reader or another assistive tool and could not. It lists barriers, often with WCAG references, asks you to fix the site and pay a settlement, and sets a deadline.

A letter is not a lawsuit. A lawsuit is filed in a court, has a case number and is served on you with a summons, and its deadlines run from the day it is served. Some businesses receive a lawsuit with no letter first, so anything that looks like court papers goes to a lawyer the same day.

A letter may read like a template. That does not make it empty. Check whether the barriers it lists are really on your site, with the tests further down this page, before you decide what it means for you.

The first week after a letter arrives

The order matters more than speed. A sensible first week looks like this:

• Do not ignore it, and do not reply, call the sender or post about it. Put the letter, the envelope or email and the date it arrived in one folder.
• Send it to a lawyer who handles ADA Title III claims. If your usual business lawyer does not, ask them to refer you. Ask what the deadline in the letter really means.
• Ask your insurance broker whether any of your policies could cover the claim, and whether it has to be reported by a date.
• Record the site as it is today, with screenshots of the pages the letter names and the date you took them. Ask your lawyer before you delete or change those pages.
• Collect every login: the website builder or hosting, the domain, and any booking or chat tool on the site. If a former designer still holds them, ask for them now.
• Check each listed barrier yourself and note which are real.
• Agree a plan with your lawyer and whoever looks after the site, starting with the barriers on the pages customers use to book, buy or contact you.

Do not buy an overlay widget as your answer to a letter. Sites with overlays installed have been sued, and the Federal Trade Commission took action in 2025 against a leading overlay seller over its compliance claims. See do accessibility overlays work.

Settling and fixing are separate questions. Whatever your lawyer advises about the letter, the barriers keep stopping customers until they are fixed, and the next letter can come from someone else.

WCAG in plain words

The Web Content Accessibility Guidelines, WCAG for short, are published by the World Wide Web Consortium, the body that sets web standards. Each version is a list of success criteria, testable statements such as "all functionality is available from a keyboard". Each criterion has a level. A is the minimum, AA is the level laws and contracts ask for, and AAA is stricter. The consortium itself advises against requiring AAA for a whole site.

Three versions are in use. WCAG 2.0 dates from December 2008, 2.1 from June 2018 and 2.2 from October 2023. Each one adds criteria to the last, so a page that meets 2.2 also meets 2.1 and 2.0. Version 2.2 adds points such as a minimum size for the buttons and links people tap, and keyboard focus that is never completely hidden behind a sticky header.

For a small business in the US, name WCAG 2.1 AA as the target today. On a new site, building to 2.2 AA costs little extra. You do not need to read the whole standard: start with the handful of criteria in the next section, because they decide whether a customer can book, buy or get in touch.

The fixes that matter most on a small site

Each fix below names the WCAG criterion it comes from, so you can point a designer straight at it.

• Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1 (criterion 1.4.3). Pale grey text on white and white text over a photo are the usual failures. Button edges and form field borders need 3:1 as well (1.4.11).
• Every form field needs a visible label that stays in place while the visitor types (1.3.1, 3.3.2). Grey placeholder text that vanishes on the first keystroke is not a label. On a dental clinic's booking form, "Preferred day" above the box works. A hint inside the box does not.
• Errors must say in words what is wrong, such as "Enter a phone number with the area code" (3.3.1). A box that only turns red tells a screen reader user nothing, and colour must never be the only signal (1.4.1).
• Everything that works with a mouse must work with the keyboard: the menu, the booking button, the cookie banner and the chat button (2.1.1). The visitor must always see where they are on the page (2.4.7) and must never get stuck inside a pop-up (2.1.2).
• Every image that carries information needs a short text alternative saying what it shows (1.1.1). For a bathroom fitter's photo: "Walk-in shower with grey tiles and a glass screen". Decorative images get an empty alt so screen readers skip them, and the logo's alt is the business name.
• Videos with speech need captions (1.2.2). Automatic captions are a start: read them through and correct names, prices and technical words before you publish.
• A menu, price list or timetable posted as a photo or a scanned PDF cannot be read aloud or enlarged cleanly. Put it on a web page as text.

Four smaller fixes are quick: set the page language in the code, give each page a title that says what it is, use headings in order, and write link text that makes sense on its own, such as "See prices for deep cleans" rather than "Click here". Then check that nothing breaks when text is enlarged to twice its size (1.4.4), or on a narrow phone screen without sideways scrolling (1.4.10).

Small details count too. On ggsites.com, for example, the first thing a keyboard reaches is a Skip to content link, every field on the project form has a written label, and the site follows the reduced motion setting of a visitor's phone or computer, with a Reduce motion button in the footer for anyone else.

Booking widgets, menus and other parts you did not build

Your site is more than the pages you wrote. A booking widget, a chat button, an embedded map, a payment page and a PDF price list are all part of what a customer meets on your site, and a letter will not care who made them. For each one:

• Try it with the keyboard and with a phone screen reader, as described below.
• Ask the supplier for its accessibility conformance report, often called a VPAT, and which WCAG version and level it meets. A supplier that has never heard the question has told you something.
• If the widget fails and the supplier's own booking page passes, link to that page instead of embedding the widget.
• Turn the documents customers need into web pages. A restaurant's menu works better as text anyway: it loads faster on a phone and Google can read it.

An online store adds the basket and checkout. Payment steps often run on the payment provider's pages, so test them with a keyboard too. If you add an AI chatbot, its button and window need the same keyboard and screen reader checks as the rest of the page, because a chat window that a keyboard cannot open or close is a barrier on every page it appears on.

How to check your own site

You can find the obvious barriers yourself, in this order:

• Run a free automated checker on your home page, one service page and the contact page: WAVE from WebAIM, or the accessibility check in Google's Lighthouse, which also runs inside PageSpeed Insights. Fix what it flags.
• Put the mouse away. Press Tab from the top of the page and work through the menu, a service page and the form. Can you see where you are each time, reach every button and send the form?
• Zoom the browser to twice its normal size on a laptop. Nothing should overlap, disappear or need sideways scrolling.
• Turn on the screen reader on your phone: VoiceOver on an iPhone, TalkBack on Android. Listen to your home page and try to send an enquiry. It is slow the first time, and it is the closest you will get to what a blind customer hears.
• Send the form with mistakes on purpose, such as a missing email address or a letter in the phone number. Each error should be announced and explained.
• Play every video with the sound off.

Automated tools find only part of the problem. The Justice Department's guidance says the same: a clean report does not mean a site is accessible, which is why the keyboard and screen reader tests matter.

For a site that takes bookings or payments, a paid audit by an accessibility specialist is worth doing once, after you have fixed what you found yourself. Ask for the results as a list of issues, each with the WCAG criterion, the page and the steps to reproduce it, so whoever fixes them can check their work.

Publish an accessibility page with a way to ask for help

An accessibility statement is a short page saying what you aim for, what you know is not right yet and how to get help. No federal rule requires one for a private business. It still earns its place, because it gives a customer who meets a barrier another way to book or buy. Keep it plain:

• The standard you are working towards, such as WCAG 2.1 AA.
• Anything you know does not work yet, and when you plan to fix it.
• A phone number and an email address for help, with a reply time you can keep.
• An offer to take the booking or the order by phone or email instead.

Do not write that the site is fully compliant unless an audit has shown it. A claim you cannot back up does not help you when a customer complains.

Write it into the brief before the next redesign

The cheapest time to get accessibility right is when a site is built or rebuilt. Put it in the brief and the contract in plain terms:

• The target: WCAG 2.1 AA, or 2.2 AA for a new build.
• Who tests, how and when: automated checks, keyboard tests and a screen reader test before launch.
• Which third-party parts are included in the testing, such as the booking widget and the payment page.
• Who fixes accessibility problems found after launch, and how quickly.

A theme sold as accessible is only a starting point. The colours, images, forms and videos you add can break it. If you are planning a website redesign, add these lines before the quotes come back, because they change the work. Our web design contract checklist covers the rest of the contract.

Where not to spend money

• An overlay widget sold as one line of code that makes a site compliant.
• A monthly scanning subscription before you have fixed the basics. A free checker run after each change does the same first job.
• A full rebuild of a site that only needs fixes. Contrast, labels, alt text and captions are usually changes to a working site.
• A badge or certificate that calls the site ADA compliant. What counts is whether a disabled customer can use it.

Spend the money on the pages that bring enquiries and on the parts customers must get through: the menu, the form, the booking step and the checkout.