WCAG 2.2 Checklist for Small Business Websites: 10 Checks for 2026

A WCAG 2.2 checklist for a small business website comes down to ten checks: text contrast of at least 4.5:1, alt text on meaningful images, a label on every form field, full keyboard operation, a focus outline that sticky bars don't cover, tap targets of at least 24×24 CSS pixels, no drag-only actions, a login that doesn't depend on memory or puzzles, help in the same place on every page, and no forced re-typing in multi-step forms. Check your homepage, contact page and checkout first, because that is where failures cost you customers. Free tools clear the most common ones in an afternoon.

Why this matters now: on September 10, 2026, the W3C published a new Working Draft of WCAG 3.0. Don't wait for it. The draft says it does not deprecate WCAG 2 and that organizations may keep using WCAG 2 for compliance, and it expects content that meets WCAG 2.2 Level A and AA to meet most of WCAG 3's minimum conformance level. Meanwhile the problem is growing: the WebAIM Million 2026 found detectable WCAG 2 failures on 95.9% of one million home pages, up from 94.8% a year earlier, at an average of 56.1 errors per page.

WCAG 2.2 Checklist: 10 Checks for a Small Business Website

Six of these ten criteria were added in WCAG 2.2 at Level A or AA (marked new). The other four are older rules that, as the data below shows, most sites still fail. Work through them in this order.

1. Text contrast (1.4.3, AA). Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Light-grey text on white is the classic failure.
2. Alt text (1.1.1, A). Every meaningful image gets an alt attribute that says what it shows or does. Decorative images get an empty alt="" so screen readers skip them.
3. Form labels (1.3.1 and 3.3.2, A). Every field has a visible, programmatically linked label. A placeholder is not a label, because it disappears as soon as someone starts typing.
4. Keyboard access (2.1.1, A). Menus, forms, dialogs and buttons work with Tab, Enter, Space and Esc alone, with no keyboard traps.
5. Focus not obscured (2.4.11, AA, new). When a link or field receives keyboard focus, it can't be entirely hidden by a sticky header, cookie banner or chat bubble.
6. Target size (2.5.8, AA, new). Click and tap targets are at least 24×24 CSS pixels, or have enough spacing around them. Tiny close icons and tightly packed social icons fail.
7. Dragging alternatives (2.5.7, AA, new). Sliders, drag-to-reorder lists and drag-and-drop uploads also work with a simple tap or click.
8. Accessible authentication (3.3.8, AA, new). Login doesn't force people to memorize or transcribe something, or solve a puzzle, unless there is an alternative. Allow pasting and password managers, and offer another route past puzzle CAPTCHAs.
9. Consistent help (3.2.6, A, new). If you show a phone number, chat button or contact link on several pages, keep it in the same place relative to the rest of the page.
10. Redundant entry (3.3.7, A, new). In multi-step forms and checkouts, don't make people type the same information twice. Pre-fill it or offer “billing address same as shipping”.

Alt text, link text and page structure also change how search engines read your pages. Run a Clariola audit to see the technical and on-page issues on your site, with a prioritised list of what to fix first.

A Real Example: What the WebAIM Million Found on 1,000,000 Home Pages

The most useful public dataset on where websites fail is the WebAIM Million, an automated scan of the top one million home pages. Its 2026 edition found six failure types that dominate the results, and the first four sit at the top of your checklist:

• Low-contrast text: 83.9% of home pages
• Missing alt text on images: 53.1%
• Missing form input labels: 51%
• Empty links: 46.3%
• Empty buttons: 30.6%
• Missing document language: 13.5%

Two lessons follow. First, the fixes are cheap: contrast, alt text and labels are usually template-level edits, not rebuilds. Second, more code is not safer. Pages that used ARIA averaged 59.1 detected errors, against 42 for pages without it. That is a correlation, not proof that ARIA causes errors, but it supports a simple rule: use native HTML elements (real buttons, real labels) before reaching for ARIA.

Don't stop at a scanner, though. Deque's coverage study analysed more than 13,000 pages from over 2,000 audits and found that its automated axe tests caught 57% of issues by volume, so a large share only shows up when a person tests. Several of the new 2.2 checks, such as whether a sticky header covers a focused link or whether help sits in the same place on every page, usually need a human eye.

How to Run the WCAG 2.2 Checklist in One Afternoon

1. Pick your key pages. Home, your top product or service page, contact or booking, and checkout. Four to six pages is enough to start.
2. Run an automated scan. Install the free axe DevTools browser extension, run WAVE from WebAIM, or open the Lighthouse accessibility audit in Chrome DevTools. Fix contrast, missing alt text, missing labels, empty links and empty buttons first, since those are the failures WebAIM finds most often.
3. Unplug the mouse. Press Tab through each page. You should always see where you are, reach every menu item and button, and be able to submit every form. Watch for sticky headers, cookie banners and chat widgets that cover the focused item (2.4.11).
4. Measure your tap targets. Right-click an icon button or footer link, choose Inspect, and read its width and height in DevTools. Anything under 24×24 CSS pixels needs padding or more space around it. Check on a real phone too; our guide to mobile-first web design covers the wider mobile conversion gap.
5. Test login and checkout. Paste a password into the login field, try a password manager, and confirm the checkout never asks twice for the same address. Our piece on reducing cart abandonment covers checkout friction more broadly.
6. Zoom in. Set browser zoom to 400%, roughly a 320-pixel-wide screen. Content should reflow into one column without horizontal scrolling or overlapping text.
7. Log, fix, retest. Record each failure in a spreadsheet with the page, the criterion and an owner. Fix template-level problems first, retest, and repeat after every redesign or plugin change. Give visitors a way to tell you when they hit a barrier.

The quick score below the article turns your answers into a number and tells you what to fix first.

Does the Law Apply to My Business?

If you sell to consumers in the EU, the European Accessibility Act (Directive 2019/882) has applied since June 28, 2025, and e-commerce services are among those it covers. Microenterprises that provide services, meaning fewer than 10 staff and turnover or a balance sheet of up to €2 million, are exempt from the service requirements. In the US the pressure comes mainly from lawsuits; we break down that risk in website accessibility lawsuits in 2026. This is not legal advice, so check your own situation with a lawyer.

Mistakes to Avoid

• Buying a plugin promise. In April 2025 the FTC approved a final order requiring accessiBe to pay $1 million over claims that its AI-powered accessWidget could make any website WCAG-compliant. A widget can help at the margins, but it does not repair broken templates. Read the FTC announcement.
• Waiting for WCAG 3.0. The draft is a work in progress, and W3C says WCAG 2 stays valid. Fixing 2.2 issues now is also your head start on 3.0.
• Adding ARIA to patch bad markup. A styled div with ARIA is worse than a real button. Start with native elements.
• Testing only the homepage. Forms, checkout and booking flows are where people actually get stuck.

When you need an audit

Work through the checklist yourself first. Bring in outside help when you see any of these signals:

• You fixed the basics but rankings and traffic haven't moved, and you can't tell whether technical problems remain.
• Your mobile PageSpeed score is poor or your Core Web Vitals fail. The same pages tend to have cramped tap targets and layout shifts (see our Core Web Vitals 2026 guide).
• Many pages lack descriptive alt text, clear headings or meaningful link text, which hurts screen-reader users and search engines alike.
• You are about to redesign, migrate or change platforms and want a baseline first.
• You need a formal WCAG conformance statement or you received a legal demand letter.

A Clariola audit is a technical and on-page SEO and AI-visibility audit with a mobile PageSpeed summary. It surfaces the overlapping problems, but it is not a WCAG conformance audit. For a formal statement or a legal matter, commission a specialist who tests manually with assistive technology.

Frequently asked questions

Does WCAG 3.0 replace WCAG 2.2?

Not yet. The September 10, 2026 draft is a work in progress, and the W3C says it does not deprecate WCAG 2. Keep targeting WCAG 2.2 Level AA.

Which WCAG 2.2 level should a small business aim for?

Level AA is the usual target. Levels A and AA together cover the ten checks in this checklist. Level AAA is not required for whole sites.

Can an accessibility plugin make my site compliant?

No plugin can guarantee compliance. The FTC's 2025 order against accessiBe barred it from claiming its automated product makes any website WCAG-compliant without evidence. Fix your templates and test with real keyboards and screen readers.

Want a clear read on how your site performs for search engines and AI systems? Get your Clariola audit and see what to fix first. Prefer Spanish? Read the versión en español.