How to test website accessibility: a 6-step method with free tools

What should a website accessibility test check against?

A website accessibility test checks pages against WCAG, the W3C's Web Content Accessibility Guidelines. The version and level depend on where your users are and which law applies to you.

If you serve more than one market, test against WCAG 2.2 AA: it is the simplest single target that includes the levels above. Background on each law: our EAA guide, the ADA website checklist and the ADA Title II rule.

Source: EUR-Lex, Pacific ADA Center, US Department of Justice (DOJ), ADA.gov, Lexpera

Step 1: Which pages should you test?

Test one page per template, plus every step of your most important flow. Most sites are built from a handful of templates, and a fix in a template fixes every page made from it. WCAG-EM 2.0, the W3C's evaluation methodology (July 2026), works the same way: a structured sample of representative pages plus a few random ones.

Source: W3C WAI

Step 2: How do you run an automated accessibility test?

Run a rules-based checker on every page in your sample. Free options are the axe DevTools browser extension, WAVE and the accessibility audits in Lighthouse. Lighthouse and our own scan both run axe-core, Deque's open-source engine. Each finding names a rule, the element and a WCAG success criterion.

Read the results in two groups. Failures are certain: an image with no alt attribute, a button with no name. Needs review items are cases the engine can't decide, such as text over a background image; axe-core reports them separately on purpose, to avoid false alarms. A clean report, like a Lighthouse score of 100, means no automatically detectable issues were found, not that the page is accessible.

A typical finding: the axe rule button-name (WCAG 4.1.2) flags an icon-only button with no accessible name. A screen reader announces it as just "button".

For more fixes like this one, see how to fix the 10 most common accessibility issues.

Source: Deque Systems, Deque Systems, GitHub, Deque Systems, WebAIM, Chrome for Developers (Google)

Step 3: How do you test with a keyboard?

Put the mouse away and complete your main flow with the keyboard alone. This step covers criteria that no axe-core rule tests: 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 2.4.7 Focus Visible and, in WCAG 2.2, 2.4.11 Focus Not Obscured.

Write down every place you get stuck, lose sight of focus or land on something you can't see. A common case is a closed cart drawer or menu whose links still take focus. When the closed panel is marked aria-hidden="true", axe-core does catch it (rule aria-hidden-focus); the fix is the inert attribute or display:none on the closed panel.

Source: W3C, Deque Systems, GitHub

Step 4: How do you test zoom and reflow?

Zoom the browser to 200% and check that no text is cut off or overlapping (1.4.4 Resize Text). Then make the window 1280 px wide and zoom to 400%. That equals a 320 CSS px viewport, the width WCAG 1.4.10 Reflow uses: content should fit in one column without scrolling sideways, except for things like data tables and maps.

On a phone, check that pinch zoom works. The axe rule meta-viewport flags a viewport tag that blocks it:

Source: W3C, Deque Systems, GitHub

Step 5: How do you test forms and error messages?

Submit each form empty, then with deliberate mistakes: an email address without @, a date in the past. Each error should be described in text next to the field; a red border alone fails 3.3.1 Error Identification. Status messages such as "Added to cart" should be announced without moving focus (4.1.3 Status Messages, Level AA).

axe-core checks that a field has a label (rule label) and that aria-describedby points to an id that exists (rule aria-valid-attr-value). It can't judge whether the error message makes sense. The fix below gives the field a visible label and ties the error text to it, so a screen reader reads both together:

Source: W3C, Deque Systems, GitHub

Step 6: How do you test with a screen reader?

Use a screen reader your users are likely to have. NVDA is free on Windows; VoiceOver is built into Mac and iPhone; TalkBack is built into Android. Fifteen minutes on your main flow shows the most obvious problems.

Listen for four things: images described usefully, prices and options read in a sensible order, buttons whose names say what they do, and an announcement after "Add to cart" or a form error.

Source: NV Access, Apple

How do you record results and keep them current?

Record each finding with the page, the step, the WCAG criterion, what happened and a screenshot. That record becomes your fix list, the evidence behind an accessibility statement and the baseline for your next test.

Re-test after every release. A site that passed in spring can fail in autumn after a theme update or a new campaign page. UsableNet counted more than 5,000 ADA digital accessibility lawsuits in 2025, and 45% of federal cases named a company that had been sued before. An automated scan can repeat step 2 every week; put steps 3–6 in your release checklist.

Be careful with what you claim afterwards. No test, ours included, proves that a site conforms to WCAG. On 22 April 2025 the US FTC finalised an order requiring accessiBe to pay $1 million and barring it from claiming without evidence that its product makes websites WCAG-compliant. Say what you tested, when, and what's still open.

Source: UsableNet, US Federal Trade Commission (FTC)