How to test a website against WCAG, step by step

Testing a website against WCAG means checking it against the success criteria of the Web Content Accessibility Guidelines, usually at level AA. No single tool does all of it. A reliable test combines an automated scan with manual testing by a person using a keyboard, browser zoom and a screen reader. Below is the routine we recommend for shops, service sites and agencies, in the order that finds the most problems with the least effort.

This is general information, not legal advice. Our own tests are an automated check, not a full audit.

Step 0: choose what to test (sampling)

You rarely test every page. The W3C Website Accessibility Conformance Evaluation Methodology (WCAG-EM) describes five steps: define the scope, explore the site, select a representative sample, evaluate the sample and report the findings. For the sample it combines a structured sample with a few randomly selected pages.

For an online shop a structured sample usually includes:

• home page, a category page, a product page, search results;
• every step of the checkout, from cart to confirmation, because WCAG requires complete processes to conform;
• login, registration, password reset and the customer account;
• contact form, help and accessibility information pages;
• pages with special content: video, maps, configurators, PDFs to download.

Write down the WCAG version and level (for example WCAG 2.2 AA), the browsers and assistive technologies you use and the date. You will need it for your accessibility statement.

Step 1: automated scan

Start with an automated tool. It is quick, repeatable and good at code-level problems: missing alternative text, low text contrast, form fields without labels, buttons and links without names, missing page language, invalid ARIA, small touch targets.

• Scan one page for free with our WCAG checker, or every page of the site with a Pandus plan.
• Check pages behind a login, the cart and the checkout with our browser extension.
• Other tools are compared in accessibility testing tools.

Fix the automated findings first. They are usually template problems: one fix in the theme removes the same error on hundreds of pages. Then go on with the manual steps, because studies disagree on how large a share of problems automation finds, but agree it is not all of them.

Step 2: keyboard testing

Put the mouse away and use only the keyboard:

Check that:

1. Everything works with the keyboard — menu, filters, product options, add to cart, checkout, cookie banner (2.1.1).
2. Focus never gets stuck in a pop-up, chat widget or embedded player (2.1.2).
3. Focus is always visible (2.4.7) and not hidden behind sticky headers or banners (2.4.11).
4. The order makes sense and follows the visual order (2.4.3).
5. A skip link or landmarks let you bypass the menu (2.4.1).
6. Dialogs move focus into them when they open and back when they close.

Step 3: zoom, reflow and text spacing

1. Zoom the browser to 200%: no text cut off, nothing overlapping, everything still usable (1.4.4).
2. Zoom to 400% or make the window 320 CSS pixels wide: text wraps, no horizontal scrolling to read (1.4.10).
3. Apply larger text spacing: nothing clipped (1.4.12).
4. Rotate a phone: the page works in portrait and landscape.

More on sizes in WCAG font size.

Step 4: screen reader testing

A screen reader shows whether the page makes sense without seeing it. Use at least one desktop and one mobile combination:

• NVDA (free, Windows) with Firefox or Chrome;
• VoiceOver (built into macOS and iOS) with Safari;
• TalkBack (built into Android) with Chrome.

Listen for:

• a meaningful page title and a heading structure you can jump through (1.3.1);
• image descriptions that say what matters (1.1.1);
• buttons and links that say what they do — "Add to cart", not "Button" (4.1.2);
• status messages, such as "Added to cart" or "3 results", announced without moving focus;
• form labels, required fields and errors read together with the field.

Learn the basic commands first: next heading, next link, next form field, read all. Screen reader users navigate by these, not line by line.

Step 5: forms and checkout

Go through every form and make deliberate mistakes:

• every field has a visible label, not only a placeholder;
• errors are described in text next to the field, with a hint how to fix them (3.3.1);
• information already entered is not asked for again (3.3.7);
• login allows password managers and pasting, and puzzles have an alternative (3.3.8);
• the autocomplete attributes for name, e-mail, address and phone are set;
• time limits can be extended, and orders can be checked before sending.

Step 6: media, colour and motion

• Videos have captions (1.2.2); audio-only content has a transcript.
• Nothing plays sound automatically for more than three seconds without a way to stop it.
• Carousels and animations can be paused.
• Colour is not the only signal for errors, availability or links in text.
• Text and controls have enough contrast; check unclear cases with the contrast checker.

Step 7: record and re-test

Record each problem with the page, the element, the WCAG criterion, a screenshot and a severity. Fix in order of impact: what blocks a purchase or a login comes first. Re-test after each release, theme update or new app — accessibility regressions are common after changes. Weekly monitoring catches the automated part of them.

When to hire an accessibility audit

Your own tests are a good routine, but they are not an audit. Consider a professional accessibility audit when you need a statement of conformance, before a launch or a public tender, after a complaint or a demand letter, or when results are unclear. An auditor tests all criteria of the level by hand, with several assistive technologies, and documents the method.

Frequently asked questions

What is WCAG testing?

Checking a website against the success criteria of the Web Content Accessibility Guidelines. It combines automated tests, which find code-level problems quickly, with manual tests by a person using a keyboard, zoom and a screen reader.

Can WCAG testing be fully automated?

No. Automated tools find only part of the problems. Whether alternative text makes sense, whether the focus order is logical or whether an error message is understandable needs a person.

How do I test keyboard accessibility?

Put the mouse away. Move with Tab and Shift+Tab, activate links with Enter and buttons with Enter or Space, use the arrow keys in menus and Esc to close dialogs. Check that the focus is always visible, follows a logical order and never gets stuck.

Which screen reader should I test with?

NVDA with Firefox or Chrome on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. Testing with one desktop and one mobile screen reader finds most problems.

How many pages should I test?

A representative sample, as the W3C WCAG-EM methodology describes: the home page, one page of each template, all steps of key processes such as checkout and login, and a few random pages.

When do I need a professional accessibility audit?

When you need a statement of conformance, before a public launch or tender, after a complaint or demand letter, or when your own tests leave open questions. An audit covers all criteria by hand; an automated check does not.

Sources

• W3C, WCAG-EM overview: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
• W3C, Easy Checks — a first review of web accessibility: https://www.w3.org/WAI/test-evaluate/preliminary/
• W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/