Website accessibility checklist for small businesses (WCAG 2.2)

A plain-English website accessibility checklist based on WCAG 2.2 AA, with quick checks a small business can run itself and what the law says today.

An accessible website is one that people with disabilities can use: someone who is blind and uses a screen reader, someone who cannot use a mouse, someone with low vision who zooms the page to 200%, someone who is colour-blind. Making a site accessible is also good business. The same fixes make pages clearer for everyone, work better on phones, and are easier for search engines and AI assistants to understand.

This checklist follows WCAG 2.2 Level AA, the current version of the Web Content Accessibility Guidelines published by the W3C in October 2023. It is written for business owners, not developers: each item says what to check and how to check it yourself.

What the law says, briefly

In the United States, the Department of Justice's position is that the Americans with Disabilities Act applies to the websites of businesses open to the public; its guidance on web accessibility says so directly. There is still no federal regulation that sets a specific technical standard for private businesses, so courts and settlements commonly point to WCAG as the benchmark.

For state and local governments, a 2024 DOJ rule adopted WCAG 2.1 Level AA as the required standard. In April 2026 the DOJ extended that rule's compliance dates by one year, to April 2027 for larger public entities and April 2028 for smaller ones. Meeting WCAG 2.2 AA also meets 2.1 AA, because 2.2 builds on it.

Five checks you can run in ten minutes

1. 1Unplug the mouse. Press Tab repeatedly from the top of your homepage. You should be able to reach every link, button and form field, see clearly where you are at each step, and use the menu and booking form with the keyboard alone.
2. 2Zoom to 200%. In your browser, zoom in twice. Text should get bigger without overlapping, being cut off or forcing you to scroll sideways to read a line.
3. 3Read the images out loud. For each meaningful image, would its description make sense to someone who cannot see it? Most site editors have an "alt text" field for this.
4. 4Check the contrast. Light grey text on white is the most common failure. Use a free contrast checker on your body text and buttons.
5. 5Try the forms. Leave a required field empty and submit. The error should say what went wrong, in words, next to the field, not only by turning it red.

Content: what everyone writes

• Alt text on informative images. Describe what the image tells the reader. Decorative images get empty alt text so screen readers skip them.
• Real headings in order. One main heading per page, then sections and subsections, using the heading styles in your editor rather than bold text made bigger.
• Descriptive links. "See our pricing" instead of "click here". Screen reader users often jump from link to link, and "click here" ten times tells them nothing.
• Captions and transcripts. Videos with speech need captions; audio-only content needs a transcript.
• Plain language. Short sentences and common words help people with cognitive disabilities, and everyone else.
• Do not rely on colour alone. "Required fields are in red" fails for colour-blind visitors. Add an asterisk or the word "required".

Design: how the page looks

What WCAG 2.2 added

If your site was built against WCAG 2.1, these are the new Level A and AA requirements to check:

• Focus not obscured: a sticky header, cookie banner or chat window must not completely cover the element that has keyboard focus.
• Target size (minimum): small tap targets, like tiny icons packed close together, need to be at least 24×24 pixels or have spacing around them.
• Dragging movements: anything done by dragging, such as a slider or a map, must also work with a simple click or tap.
• Consistent help: if you offer help (a phone number, chat, a contact link), put it in the same place on every page.
• Redundant entry: do not make people type the same information twice in one process; fill it in for them or let them select it.
• Accessible authentication: logins must not depend on remembering or transcribing something, such as a puzzle, unless there is an alternative. Allowing password managers and paste helps here.

Code: what your developer checks

• The page declares its language (lang="en", or lang="es" on Spanish pages).
• Every form field has a real label connected to it, not only placeholder text.
• Custom menus, tabs and pop-ups work with the keyboard and announce their state to screen readers.
• Pop-ups and dialogs can be closed with the Escape key and return focus to where the user was.
• Animation respects the "reduce motion" setting on the visitor's device.
• Nothing flashes more than three times per second.

A word on accessibility overlay widgets

Some products promise to make any site compliant by adding one script. They can offer useful display options, but they cannot fix missing alt text, unlabeled forms or a menu that keyboard users cannot open, because those problems live in the site itself. Treat an overlay as an extra at most, never as the fix.

How to test properly

Automated checkers such as browser accessibility audits find a useful share of problems quickly: missing alt text, low contrast, unlabeled fields. They cannot judge whether alt text is meaningful or whether a booking flow makes sense with a screen reader. Combine an automated scan with the manual checks above, and ideally a test with the screen reader built into your phone or computer (VoiceOver on Apple devices, TalkBack on Android, Narrator on Windows).

Publish an accessibility statement

Add a page that says which standard you aim for, known limitations you are working on, and how someone can contact you if they hit a barrier. It shows good faith and gives visitors a way to reach you before they give up. Serverlys publishes its own.