Web accessibility testing: a practical method

What web accessibility testing covers

A complete test looks at a site in four layers, each catching things the others miss:

• Automated scans flag code-level faults quickly across many pages.
• Manual checks by a trained tester cover keyboard use, zoom, contrast in tricky places, reading order and form behavior.
• Assistive technology tests confirm that screen readers, voice control and magnifiers get the right names, roles and announcements.
• Testing with disabled users shows whether real people can finish real tasks, which no checklist fully predicts.

Testing against a standard means picking a version and level. The latest WCAG version is 2.2, published by W3C, and most projects test against Level AA, which is 55 success criteria. WCAG 3.0 is only a working draft, so do not test against it yet. See WCAG 2.2 for the details and WCAG 3.0 for the draft.

Automated WCAG testing: fast but partial

Start with a tool. Lighthouse is built into Chrome. WAVE, axe DevTools and Accessibility Insights are free browser extensions. Online scanners and paid platforms test many pages at once.

Expect them to find something like a third of the issues on a typical site, according to many published estimates. They are excellent at missing labels, missing alt attributes, low text contrast and broken ARIA references. They have no way to judge if alt text is accurate, whether a dialog traps focus correctly or whether an error message makes sense. A clean automated report means you are ready to begin manual testing, nothing more. The WCAG checker page compares tool types and their limits.

Manual checks anyone on the team can run

These need no special software and catch many of the failures that matter most:

• Keyboard only. Unplug the mouse. Move with Tab and Shift+Tab, activate with Enter and Space, use arrow keys in menus and radio groups, close dialogs with Esc. Every control must work, focus must be visible, and nothing should trap you.
• Zoom. Set the browser to 200 percent, then 400 percent on a 1280 px wide window. Text must stay readable and the page should scroll in one direction only.
• Text spacing. Apply larger line, letter and word spacing with a user stylesheet and look for clipped text.
• Contrast. Check text over images, placeholder text, focus rings and buttons in hover state with a contrast checker.
• Structure. Review the heading outline and link text out of context.
• Forms. Submit with mistakes and read the errors: do they say which field and what to do?

Screen reader testing

Use the screen reader your users are most likely to have. Common pairs are NVDA with Firefox or Chrome on Windows, JAWS with Chrome or Edge, VoiceOver with Safari on a Mac or iPhone, and TalkBack with Chrome on Android. NVDA is free; VoiceOver, TalkBack and Windows Narrator are built in.

Listen for four things on each page: does every image and control have a sensible name, are headings and landmarks there to jump between, do custom widgets announce their role and state (expanded, selected, checked), and are status messages such as “3 results” spoken without moving focus? The screen reader testing guide lists the key commands, and the NVDA page covers installing and turning it on and off.

A practical WCAG test order for one page

Run the layers in this order so that cheap checks clear the noise before slow ones:

The WCAG checklist lists all 55 AA criteria so you can tick them as you go.

Accessibility testing inside a development team

Testing at the end of a project is the most expensive way to do it. Teams that keep sites accessible spread the work out: designers check contrast and focus states in mockups, developers run an automated check on each component, code review includes a short keyboard test, and QA adds screen reader checks to the definition of done.

A simple example of what code review should catch: an icon-only button with no accessible name.

<button class="search-btn">
  <svg aria-hidden="true">...</svg>
</button>

<button class="search-btn" aria-label="Search">
  <svg aria-hidden="true">...</svg>
</button>

Testing with disabled users

Usability sessions with people who use assistive technology every day reveal problems a conformance test can pass over: a checkout that is technically keyboard accessible but takes 90 key presses, or labels that are present but confusing. Recruit participants with a range of disabilities, pay them for their time, let them use their own devices and settings, and watch them complete tasks that matter to your business.

User testing does not replace WCAG testing, and WCAG testing does not replace it. The first tells you what is hard to use; the second tells you what fails the standard your contract or the law refers to.

Web accessibility testing services, courses and jobs

Bring in outside help when you need an independent report, for a legal or procurement reason, or when your team has never tested before. An accessibility audit is the formal version of the testing on this page; the accessibility services guide explains how to choose a provider and what red flags to watch for.

If you want to learn testing yourself, W3C runs a free Digital Accessibility Foundations course, and training and certification lists the main professional credentials. Testing skills are in demand in QA, development and consulting roles; see accessibility jobs.