Skip to main content
Perceivly: Perceivly home
Log inStart free trial

Guides

Website accessibility checklist for small businesses (WCAG 2.2 AA)

A prioritized WCAG 2.2 AA checklist for small business websites: what to fix first, how to test each item in minutes, and code examples.

By Perceivly team · Published · 10 min read

WCAG 2.2 has 55 success criteria at levels A and AA. Most small businesses don’t have the time to read them all, and they don’t need to start there. A few problems cause most of the barriers people actually hit, and they are cheap to fix. This checklist puts them in order: what blocks people completely comes first, then what makes pages hard to use, then media, time limits and motion.

The problems are common. In February 2026, WebAIM tested the home pages of the top one million websites and found detectable WCAG failures on 95.9% of them, with an average of 56.1 errors per page. Six kinds of error made up most of what they found (WebAIM Million 2026):

  • Low contrast text: 83.9% of home pages
  • Images without alternative text: 53.1%
  • Form inputs without labels: 51%
  • Links with no text: 46.3%
  • Buttons with no text: 30.6%
  • No page language set: 13.5%

Every one of those is on this list, and every one can be fixed in your templates once instead of page by page.

Before you start

  • Pick your key pages. The home page, a typical content page, a product or service page, the contact form, and every step of your checkout, booking or sign-up. Most sites are built from a handful of templates, so fixing a template fixes every page that uses it.
  • Run an automated check on each one. The free checker tests one page against the automated WCAG 2.2 A and AA rules in a real browser. Automated tools find only part of the problems: when the UK government tested ten tools on a page with 143 known barriers, the best tool found 37 to 41% of them and all ten together found 71% (GDS, 2017). The manual checks below cover much of the rest.
  • Put the mouse away. Several checks below only need a keyboard and five minutes.

Priority 1: fix what blocks people

These stop someone from finishing a task at all. Fix them first, on your key pages.

1. Every image has the right alt text

Screen readers read the alt attribute in place of the image. An informative image needs a short description of what it shows or means here. A purely decorative image needs an empty alt="" so it is skipped. A missing alt is the worst case: many screen readers then read the file name.

<!-- Informative -->
<img src="boot-side.jpg" alt="Red leather ankle boot, side view">

<!-- Decorative -->
<img src="divider-wave.svg" alt="">

Criterion: 1.1.1 Non-text Content. Our guide on how to write good alt text covers the hard cases, and the alt text checker lists every image on a page with its alt.

2. Every form field has a label

A placeholder is not a label: it disappears as soon as someone types, and some screen readers don’t read it. Give every field a visible <label> tied to it with for and id. Groups of radio buttons or checkboxes need a <fieldset> with a <legend>.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

<fieldset>
  <legend>Delivery</legend>
  <label><input type="radio" name="delivery" value="standard"> Standard</label>
  <label><input type="radio" name="delivery" value="express"> Express</label>
</fieldset>

The autocomplete attribute lets browsers fill in known details, which helps people with motor and memory disabilities (1.3.5 Identify Input Purpose). Criteria: 3.3.2 Labels or Instructions, 1.3.1 Info and Relationships.

3. Every link and button has a name

Icon-only buttons are the usual culprit: a cart icon, a hamburger menu, a close cross, social media logos. A screen reader announces them as just “button” or “link”. Give each one a text name.

<!-- Before: announced as "button" -->
<button><svg>…</svg></button>

<!-- After: announced as "Open menu, button" -->
<button aria-label="Open menu"><svg aria-hidden="true">…</svg></button>

Link text should also make sense on its own or with its sentence. “Read more” five times on one page tells a screen reader user nothing; “Read more about our repair service” does. Criteria: 4.1.2 Name, Role, Value and 2.4.4 Link Purpose (In Context).

4. Everything works with a keyboard

Many people can’t use a mouse: people who are blind, people with tremors, people using switch devices or voice control. Test it yourself:

  1. Click in the address bar, then press Tab repeatedly to move through the page.
  2. Use Shift+Tab to go back, Enter to follow links, Space or Enter to press buttons, arrow keys inside menus and radio groups, and Escape to close dialogs.
  3. Open the menu, add something to the cart, fill in the contact form and submit it. Everything you can do with a mouse must work.
  4. Check that you never get stuck: focus must be able to leave every widget, including embedded maps and video players.

The most common cause of failure is a <div> or <span> with a click handler instead of a real <button> or <a href>. Native elements get keyboard support for free. Criteria: 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order.

5. You can always see where the focus is

While you tab through the page, each link, button and field should show a clear outline. Many themes remove it with outline: none. Put one back, and make sure a sticky header or cookie banner doesn’t cover the focused element.

:focus-visible {
  outline: 2px solid #2f5bea;
  outline-offset: 2px;
}

/* Keep focused elements clear of a 64px sticky header */
html {
  scroll-padding-top: 72px;
}

Criteria: 2.4.7 Focus Visible and, new in WCAG 2.2, 2.4.11 Focus Not Obscured (Minimum).

6. Text has enough contrast

Normal text needs a contrast ratio of at least 4.5:1 with its background; large text (24px, or about 18.7px bold) needs 3:1. Icons, input borders and focus outlines need 3:1 against what is next to them. Light grey text on white and white text on a bright brand color are the usual failures. Check your brand pairs once with the contrast checker and write the passing ones into your style guide. Criteria: 1.4.3 Contrast (Minimum) and 1.4.11 Non-text Contrast.

7. The page language is set

One attribute tells screen readers which voice and pronunciation to use. Without it, an English screen reader may read your German page with English rules, which is close to unintelligible.

<html lang="en">

Criterion: 3.1.1 Language of Page. Passages in another language get their own lang (3.1.2).

Priority 2: make pages easy to understand and navigate

These don’t usually stop a task, but they make it slow, confusing or tiring.

8. Each page has a unique, descriptive title

The <title> is the first thing a screen reader announces and what people see in tabs and bookmarks. “Contact us | Acme Bikes” beats “Home” on every page. Criterion: 2.4.2 Page Titled.

9. Headings form an outline

Screen reader users jump between headings to skim a page, the way sighted people scan bold text. Use one <h1> for the page’s topic, <h2> for its sections and <h3> inside those. Don’t pick heading levels for their size, and don’t make text look like a heading with bold alone. The heading checker shows a page’s outline. Criteria: 1.3.1 Info and Relationships and 2.4.6 Headings and Labels.

10. Landmarks and a skip link

Wrap the main areas of your template in <header>, <nav>, <main> and <footer>, and add a “Skip to content” link as the first thing in the page, so keyboard users don’t have to tab through the whole menu on every page.

<a class="skip-link" href="#main">Skip to content</a>
<header>…</header>
<main id="main" tabindex="-1">…</main>

.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }

Criterion: 2.4.1 Bypass Blocks.

11. Form errors say what went wrong and how to fix it

A red border alone doesn’t work for people who can’t see red, or can’t see at all. Write the error in text, next to the field, and connect it so screen readers read it with the field.

<label for="phone">Phone number</label>
<input id="phone" type="tel" aria-invalid="true" aria-describedby="phone-error">
<p id="phone-error">Enter a phone number with the area code, like 030 1234567.</p>

On submit, move focus to the first field with an error, or to a summary of errors at the top. Criteria: 3.3.1 Error Identification and 3.3.3 Error Suggestion.

12. Status messages are announced

“Added to cart”, “3 results found” and “Message sent” often appear without moving focus, so a screen reader user never hears them. Put them in a live region that exists in the page before the message is inserted.

<p role="status" id="cart-status"></p>
<script>
  document.getElementById("cart-status").textContent = "Added to cart: 1 item";
</script>

Criterion: 4.1.3 Status Messages.

13. Color is never the only signal

Links in body text need an underline (or another non-color cue), required fields need more than a red asterisk’s color, and charts need labels or patterns as well as colors. Criterion: 1.4.1 Use of Color.

14. The page works zoomed in and on a narrow screen

Zoom your browser to 200%: all text must still be readable and nothing may be cut off. Then zoom to 400% (or make the window 320 CSS pixels wide): the content should reflow into one column without sideways scrolling, apart from things like maps and wide data tables. Fixed heights on text boxes and overflow: hidden are the usual causes. Criteria: 1.4.4 Resize Text, 1.4.10 Reflow, 1.4.12 Text Spacing.

15. Targets are big enough to hit

Since WCAG 2.2, pointer targets must be at least 24 by 24 CSS pixels, or have enough space around them. Tiny social icons, close buttons and pagination numbers often fail. Links inside a sentence are exempt. Criterion: 2.5.8 Target Size (Minimum).

16. Pop-ups on hover can be dismissed and kept open

Tooltips and menus that appear on hover or focus must be dismissible with Escape, must stay open while the pointer moves onto them, and must not vanish on a timer. Criterion: 1.4.13 Content on Hover or Focus.

Priority 3: media, time limits and motion

17. Video has captions, audio has a transcript

Prerecorded video with speech needs accurate captions; automatic captions are a starting point, not a finished result, because they get names, numbers and product terms wrong. Audio-only content such as a podcast needs a transcript. If important information is only shown visually in a video, it needs audio description or a text alternative. Criteria: 1.2.1, 1.2.2 Captions, 1.2.5 Audio Description.

18. Moving content can be paused

Auto-rotating carousels, background videos and animated banners that run for more than five seconds need a pause button. Audio that plays on its own for more than three seconds needs a way to stop it. Criteria: 2.2.2 Pause, Stop, Hide and 1.4.2 Audio Control. Nothing should flash more than three times a second (2.3.1).

19. Time limits can be extended

If a booking hold or session expires, warn people before it does and let them extend it with a simple action. Criterion: 2.2.1 Timing Adjustable.

New in WCAG 2.2: what to check on top

WCAG 2.2 became a W3C Recommendation in October 2023 and added six criteria at levels A and AA (it also removed 4.1.1 Parsing). Items 5 and 15 above cover two of them. The other four:

  • 2.5.7 Dragging Movements: anything done by dragging, such as a price slider or reordering a list, also works with single clicks or taps.
  • 3.2.6 Consistent Help: if you offer contact details, a chat or a help link on several pages, keep it in the same place on each.
  • 3.3.7 Redundant Entry: don’t ask for the same information twice in one process. Offer “same as delivery address” for billing.
  • 3.3.8 Accessible Authentication (Minimum): logging in must not depend on a memory or puzzle test. Allow password managers and pasting into password and code fields; a CAPTCHA that asks people to transcribe distorted text needs an alternative.

Don’t forget what you didn’t build

  • Third-party widgets. Booking engines, payment forms, chat bubbles, cookie banners and embedded maps are part of your page as far as your visitors are concerned. Test them with the keyboard like everything else, and ask the vendor for their accessibility conformance report when one fails.
  • PDFs. Menus, price lists and brochures are often PDFs exported without tags. Publish the content as a web page where you can, or export a tagged PDF.
  • Content edits. Most new problems arrive with new content: an image without alt text, a heading skipped, a “click here” link. Add a two-line checklist to your publishing routine.

Skip the accessibility overlay widgets that promise to fix all of this with one line of JavaScript. They don’t; see why overlays don’t make a site accessible.

A one-hour test plan

  1. 10 minutes: run an automated check on your key pages and note the critical and serious issues.
  2. 15 minutes: keyboard pass through your main task, from the home page to a sent form or a finished order.
  3. 10 minutes: zoom to 200% and 400%, and try the site on a phone.
  4. 20 minutes: a screen reader pass. VoiceOver is built into macOS (Cmd+F5) and iOS; NVDA is free for Windows. Listen to your main page: are images, buttons and form fields announced in a way that makes sense?
  5. 5 minutes: write down what you found, by priority, and who fixes it.

This won’t replace a full audit by an expert, which you need if you have to show conformance to a client, a buyer or a regulator. It will catch most of the problems that stop people on a small business site.

Keep it that way

Sites change every week, so a check done once goes stale. Publish an accessibility statement that says what you tested, what you know is not yet fixed and how people can reach you if something doesn’t work for them. If you sell to consumers in the EU, the European Accessibility Act may require you to publish this kind of information.

Perceivly helps you find and track the issues automated tests can detect: it crawls your site on a schedule, opens an issue for every failing rule and closes it when the fix is live (see monitoring). Like every automated tool, it covers only part of WCAG; the keyboard, zoom and screen reader checks above still need a person.

Sources