Manual Tests for Accessibility

What are manual tests for accessibility?

Manual tests for accessibility are checks a person carries out by hand to find barriers that disabled users meet: operating the page with only a keyboard, listening to it with a screen reader, and zooming in until the layout has to adapt. They cover what automated accessibility testing cannot judge, such as whether alt text makes sense or whether the focus order follows the visual order.

The three core passes

1. Keyboard-only pass

Put the mouse aside and press Tab from the top of the page. You should be able to reach and operate every link, button and form control, see where focus is at all times, leave every element again (no keyboard traps), and move in a logical order. W3C's Easy Checks also look for a skip link to the main content as the first focusable element. See keyboard navigation order for what a sensible sequence looks like.

2. Screen reader pass

Turn on a screen reader: NVDA on Windows (free) or VoiceOver on macOS and iOS (built in). Check that the page title is read first, that headings give a usable outline, that images, buttons and links have meaningful names, and that form fields announce their labels and errors. W3C notes that an experienced screen reader user gives the best result, but anyone can spot first problems this way.

3. Zoom and reflow pass

Enlarge the page and check that text and images stay readable and usable. WCAG 2.2 success criterion 1.4.10 (Reflow, level AA) asks that vertical-scrolling content works at a width of 320 CSS pixels, which is a 1280 pixel window at 400% zoom, without scrolling in two dimensions. Text should also be resizable to 200% (criterion 1.4.4). Exceptions exist for content that needs two-dimensional layout, such as maps and data tables.

Other quick manual checks

• Page title and language are set and correct.
• Headings describe the page like a table of contents.
• Colour contrast is sufficient for text and interface parts.
• Every form field has a visible label and required fields are marked.
• Videos have captions, and audio has a transcript.

Common mistakes

• Testing once at the end. Run the passes on each key flow (sign-up, checkout, search) whenever it changes.
• Treating a pass as proof. W3C warns that a page can pass the Easy Checks and still have significant barriers.
• Only testing one screen reader. Behaviour differs between NVDA, VoiceOver and others, so repeat important flows on at least two.
• Skipping real users. Testing by developers finds many defects, but people who use assistive technology daily find the ones that matter most.

How it fits with automated tests and monitoring

Automated tools catch the mechanical problems fast, manual passes judge meaning and usability, and a formal accessibility conformance test against WCAG combines both. For the automated side, LoadFocus page speed monitoring runs scheduled Lighthouse audits that include an Accessibility score, so regressions show up between manual reviews. It does not replace the manual passes above. More background in performance testing and accessibility metrics.

FAQ: Manual accessibility testing

Why do I need manual tests if I run automated ones?

Automated tools can detect a missing alt attribute, but only a person can judge whether the text describes the image in context. The same goes for focus order, reading order and error messages.

Which screen reader should I use?

NVDA is free and common on Windows, and VoiceOver is built into macOS and iOS. Start with the one you can run today, then repeat key flows on a second.

How long does a manual pass take?

A first keyboard, zoom and screen reader check of one page often takes well under an hour. Full audits of a whole site take longer and are best planned per release.

Do the W3C Easy Checks prove my site is accessible?

No. They are quick checks for a few common issues, and a page can pass them and still have barriers. Use them as a starting point before a fuller evaluation.