The ADA Website Compliance Checklist for Small Businesses (2026)

If you run a small business with a website, you have probably heard that it needs to be “ADA compliant,” and then found that nobody can tell you exactly what that means. This guide is for you: the owner who wants a plain-English list of things to actually check, not a legal treatise. It is educational information, not legal advice, but it will give you a concrete place to start.

Here is the honest situation. The ADA itself does not list technical rules for websites. There is no government form that says “check these 40 boxes and you’re done.” What exists instead is a widely adopted technical standard called the Web Content Accessibility Guidelines (WCAG). The version cited in nearly every US legal context is WCAG 2.1 Level AA, and both courts and the Department of Justice reference it as the practical benchmark. So when people say “ADA website compliance,” what they operationally mean is “meets WCAG 2.1 AA.” That is the target this checklist is built around.

WCAG organizes everything under four principles: content must be Perceivable, Operable, Understandable, and Robust. The checklist below follows those four buckets. Each item is written so you can verify it yourself with a little patience. No developer is required to find the problems, though you’ll usually need one to fix them.

Perceivable: can everyone take in the content?

• Every image that conveys information has alt text that describes it. Decorative images that add nothing are marked so a screen reader skips them, rather than reading out a filename.
• Videos have accurate captions, and audio-only content has a transcript. Auto-generated captions that are full of errors do not count.
• Color is never the only way information is conveyed. If a required field is marked only by turning red, a colorblind user misses it. Add a label, an icon, or text.
• Text has enough contrast against its background to be readable. Light gray text on a white background is the single most common failure here.
• The page still makes sense when you zoom the browser to 200%. Content should reflow rather than get cut off or overlap.
• Text is real text, not an image of text. Words baked into a graphic can’t be resized, read aloud, or selected.

Operable: can everyone use it?

• You can reach and operate every menu, form, and button using only the Tab, Enter, and arrow keys, with no mouse. This one test catches a surprising number of problems.
• There are no keyboard traps. If a popup or modal opens, you can close it and get back out with the keyboard alone. Getting “stuck” inside a chat widget or newsletter popup is a classic barrier.
• When you Tab through the page, the focused element is clearly visible (an outline or a highlight), so a keyboard user always knows where they are.
• The tab order follows the visual order of the page. Focus shouldn’t jump around unpredictably.
• Anything that moves, blinks, or auto-plays can be paused or stopped, and nothing flashes rapidly in a way that could trigger a seizure.
• There’s a way to skip repetitive navigation, usually a “skip to main content” link, so keyboard and screen-reader users don’t have to tab through the whole menu on every page.
• Links and buttons make sense on their own. “Click here” and “read more” repeated twenty times tell a screen-reader user nothing.

Understandable: is it clear and predictable?

• The page language is declared (for example, English) so screen readers pronounce content correctly.
• Form fields have visible labels, not just placeholder text. Placeholder text disappears the moment you start typing and is often invisible to assistive technology.
• Error messages identify the specific field and say how to fix it. “Enter a valid email address” beats a generic red “Error.”
• Navigation stays consistent from page to page. The menu shouldn’t reorder itself or rename items as users move around.
• Nothing surprising happens just because an element gets focus. A dropdown shouldn’t auto-submit or navigate away the instant you tab into it.

Robust: does it work with assistive technology?

• Form inputs, buttons, and links use proper HTML so screen readers announce them correctly (a real button element, not a styled div that only responds to a mouse).
• Custom components (tabs, accordions, sliders, modals) expose their name, role, and state to assistive technology, so a screen-reader user knows what something is and whether it’s open or selected.
• Status messages (“Item added to cart,” “Form submitted”) are announced to screen readers, not just shown visually.
• The page’s underlying code is valid enough that assistive technology can parse it reliably.

What a checklist can’t catch

Here is the part most “free checklist” articles leave out: a checklist only takes you so far. Automated scanners catch roughly 30% of WCAG issues: the mechanical ones like missing alt text and contrast. A careful self-check with the list above gets you further, because you can test keyboard operation and read your own error messages. But the remaining issues are the ones that require a human actually using assistive technology.

Those include the full screen-reader experience of completing your checkout or contact flow, subtle keyboard traps that only appear in specific interaction sequences, whether custom widgets truly announce their state, and cognitive-load problems where a page is technically “passable” but genuinely confusing to navigate without sight. These are exactly the barriers that get cited in demand letters, and no tool or checklist reliably surfaces them.

How to use this checklist

Work it in two passes. First, self-check. Go through the list above on your own most important pages: your homepage, your contact or booking flow, and your checkout if you sell online. Just unplugging your mouse and trying to complete a purchase with the keyboard will teach you more than any scanner. Fix the obvious things you find.

Second, get a professional manual audit for what you can’t verify yourself. A manual audit against WCAG 2.1 AA gives you a criterion-by-criterion pass/fail record, severity ratings, and developer-ready remediation notes for the roughly 70% of issues a self-check and a scanner will miss. It also produces a dated, signed record of the effort, which matters if a claim is ever filed. You can see exactly what a manual audit covers and how it differs from an automated scan.

FAQ

Is there an official ADA website checklist? No. The ADA statute doesn’t list technical web criteria. WCAG 2.1 AA is the standard courts and the DOJ reference in practice, so a WCAG-based checklist like this one is the closest thing to an authoritative starting point.

Does passing a free scanner mean I’m compliant? No. Automated scanners catch roughly 30% of issues. A clean scanner report tells you the mechanical basics look okay. It says nothing about the keyboard, screen-reader, and interactive-flow barriers that make up most real accessibility problems.

I got a demand letter — is this checklist enough? No. If you’ve received a demand letter, a self-check is not the right first move. Read our guide on what to do if you get an ADA demand letter and understand what a WCAG audit actually involves before you respond.