ADA compliance website guide: how the ADA and WCAG fit together

What the ADA says about websites

The ADA is older than the public web, so its text never mentions websites. Two parts of it matter online.

• Title III covers businesses that serve the public, which the law calls places of public accommodation: shops, hotels, banks, clinics, restaurants and many more. Courts have read it to reach websites and apps, especially when they connect to a physical location. Courts in different parts of the US disagree about businesses that exist only online, which is one reason legal advice matters.
• Title II covers state and local governments: cities, counties, public schools, public universities, courts and transit agencies. A DOJ rule now sets a technical standard for their web content and mobile apps.

The DOJ explains its position in plain language on its web guidance page. It says businesses and governments must make online services accessible, and it points to WCAG as a helpful yardstick.

ADA vs WCAG vs Section 508

People mix these three names up all the time. One is a civil rights law, one is a technical standard, and one is a procurement rule for the federal government.

So ADA and WCAG compliance are not two separate jobs. WCAG tells you what to build and test; the ADA is the reason many US organizations have to do it. If you sell to federal agencies, you will also meet Section 508 and its paperwork, explained on our accessibility laws page.

Title II and public bodies

The DOJ adopted WCAG 2.1 Level AA as the standard for the websites and mobile apps of state and local governments. Larger public bodies, those serving 50,000 people or more, have the earlier compliance date, and smaller ones get an extra year.

The rule lists some exceptions, for example certain archived content that nobody edits or uses for current business. Read the exact wording on ada.gov before you lean on an exception, because each one has conditions.

What an ADA compliance website needs in practice

Most barriers that show up in lawsuits and audits are the same handful of WCAG 2.1 AA problems. Fix these and you remove most of the risk and most of the frustration for users.

• Text alternatives. Every meaningful image has useful alt text, and decorative images have an empty alt. See what alt text is.
• Contrast. Body text should reach 4.5:1 contrast or better, and large headings 3:1. Check pairs with our contrast checker.
• Keyboard access. Menus, filters, sliders, date pickers and checkout steps all work without a mouse, and the focus indicator stays visible.
• Forms. Each field has a label, required fields are marked in text, and errors are described in words, not just with red borders.
• Structure. Real headings, lists, tables and landmarks, so screen reader users can jump around.
• Media. Prerecorded video carries captions; audio-only content comes with a transcript.
• Zoom and reflow. The page still works at 200 percent text size and on a narrow screen.

The full list of the 50 criteria at this level is on our WCAG 2.1 AA page.

How to test a site against WCAG for ADA purposes

Testing has two halves. Automated tools are quick and catch easy errors, but they miss a lot; many sources estimate they spot around a third of issues. The rest needs a person.

1. Pick a sample: the home page, each template, and the journeys that matter most, such as sign up, search, checkout or booking.
2. Run an automated checker on every page in the sample and fix the clear errors first. Our guide to WCAG checkers compares the free options.
3. Put the mouse away and complete each journey with Tab, Shift+Tab, Enter and the arrow keys.
4. Zoom the browser to 400 percent and look for cut off text or sideways scrolling.
5. Try the same journeys with a screen reader and listen for missing names, wrong order and silent errors.
6. Record each issue with the page, the WCAG criterion and how serious it is.

For a deeper method see accessibility testing, or read how a formal accessibility audit works if you want an outside review.

Demand letters, lawsuits and what courts look at

Many web cases start with a demand letter rather than a court filing. A tester, often a blind person using a screen reader, tries to use the site, hits barriers, and a law firm writes to the owner. Settlements usually ask for a few common things:

• bring the site up to WCAG 2.1 AA within an agreed period;
• name a person who is responsible for accessibility;
• train staff who build and publish content;
• test regularly, often with an outside auditor, and report progress;
• publish an accessibility statement with a contact route.

Nobody can promise that a site will never face a claim. What you can do is show steady, documented work toward WCAG AA, which is what regulators and courts tend to look at.

Picking between 2.1 AA and 2.2 AA

The Title II rule and most settlements name WCAG 2.1 AA. Version 2.2 at AA contains every 2.1 AA requirement (apart from 4.1.1 Parsing, which was removed as obsolete) and adds a few more, such as visible focus that is not hidden by sticky headers and a minimum size for click and tap targets. Building to 2.2 AA therefore covers 2.1 AA too, and it prepares you for contracts and other countries that already ask for 2.2. See WCAG 2.2 AA for the extra criteria.

Keeping the site accessible after the first fixes

Accessibility drifts. A new campaign page, a third party chat button or an untrained editor can undo months of work in a day. A few habits keep it steady:

• Put accessibility checks into design reviews and code reviews, not only at launch. Our accessible web design page covers what designers own.
• Train editors to write alt text, use headings and avoid text in images. See training and certification options.
• Ask vendors for an accessibility conformance report before you buy plugins, booking tools or payment widgets.
• Review the accessibility statement whenever you retest, and answer every report from a user.