Resources · Testing by hand

Manual accessibility testing seven passes, in the order that finds the most first

The analyzer settles 11 of the checklist’s 50 checks on its own and narrows down 23 more. The other 16 need a person. These are the passes that settle them, in order: what to do, what a failure looks like, and which checks each pass decides.

Why by hand

What automation cannot establish

Each row is a rule the analyzer really runs, what that rule settles, and what it leaves for you. A clean report means the rules found nothing. It does not mean the right-hand column was checked.

Rules the analyzer runs, set against what each leaves to a person
Checklist checkAnalyzer rulesWhat the rules settleWhat only a person can settle
Every image is either described or explicitly decorative image-alt image-alt-filename image-alt-placeholder That an alt exists, and is not a file name or a word like “image”. Whether it says what the image is for.
Body text reaches 4.5:1, large text 3:1 color-contrast Text on a solid background, in the state the page was scanned in. Text over images and gradients, hover and focus states, and the other theme.
Focus is always visible, and never removed without a replacement focus-visible A stylesheet that removes the outline with nothing in its place. Whether every stop shows a ring you can see, in every theme.
Every interactive element is reachable and operable by keyboard keyboard-handler-focusable scrollable-region-focusable A click handler on something that cannot take focus, and a scrolling box the keyboard cannot reach. Whether the whole task can be done from the keyboard.
No keyboard trap — focus can always get back out No rule Nothing. A trap only shows when you try to leave it. Tab into every widget and out again.
Focus is managed across route changes and dialogs No rule Nothing. Where focus goes after a click is behaviour, not markup. Whether focus moves into a dialog when it opens and back when it closes.
Headings describe structure, not size heading-order empty-heading Skipped heading levels and empty headings. Whether each heading describes what follows it.
Link text makes sense out of context link-name link-name-generic Links with no name, and names from a list of generic phrases. Whether each link says where it goes.
Status messages reach a live region status-messages aria-live-valid Live regions that are set up wrongly. Every page gets a review note, because messages appear later. Whether a message is announced when it appears.
Errors are identified in text and tied to the field error-identification A field marked invalid with no text message tied to it. Whether the message says how to fix the error, and is announced.
Video has captions; audio has a transcript video-caption That a captions track exists. Whether the captions are accurate, complete and in time.
No horizontal scroll at 320 CSS pixels wide reflow-fixed-width Fixed widths wider than 320 pixels in the CSS. Whether anything is cut off or overlaps at 400% zoom.

The order

Seven passes

Each pass assumes the one before it is done. The early ones are quick and find the most; the screen reader pass is slower, and goes better on a page that already works from the keyboard.

Pass 1 of 7

Run the automated pass first

Rules are quick and never tire, and every finding they settle is one you will not trip over by hand. Fix what they find before you start, so the manual passes spend their time on what rules cannot see.

Do this

  1. Run the analyzer on the page and work through its failures. The fix directory has a reproduction, a fix and a way to verify each of the common ones.
  2. Note what it marks for review. Each of those is a question for one of the passes below.
  3. Remember what the rules saw: the page as it loaded. Open menus, error states and dialogs are for the passes that follow.

Back to the passes

Pass 2 of 7

Keyboard only

Put the mouse out of reach and do the page’s main task from start to finish. Most of what this pass finds turns up in the first few minutes.

The keys a keyboard pass uses
KeyWhat it should do
Tab and Shift+TabMove to the next or the previous control, in reading order
EnterFollows a link, presses a button, submits a form
SpacePresses a button, ticks a checkbox
↑ ↓ ← →Move within a group: radio buttons, tabs, menus, sliders
EscCloses a dialog, menu or popup, and puts focus back on what opened it

Do this

  1. Start in the address bar and press Tab. The first stop is a skip link; press Enter and focus moves past the header.
  2. Tab through everything. At every stop you can see where you are, and the order follows the page.
  3. Open every menu, dialog and disclosure, use it, and close it with Escape. Focus goes in when it opens and comes back to the button when it closes.
  4. Finish the task: fill in the form, make a mistake, correct it, submit.
  5. On a Mac, Safari moves Tab between form fields only, until you turn on “Press Tab to highlight each item on a webpage” in its Advanced settings. Option-Tab reaches everything either way.

A failure looks like

  • Focus disappears, or sits behind a sticky header.
  • Something you can click cannot be reached, or does nothing on Enter or Space.
  • Focus goes into something and cannot get out.
  • Focus jumps around the page instead of moving through it.

Back to the passes

Pass 3 of 7

Zoom, reflow and text spacing

People with low vision enlarge the page, and many override its spacing. The content has to survive both with nothing cut off, covered or lost.

Do this

  1. Zoom to 200% (Ctrl and + on Windows, Command and + on a Mac). All the text grows, and nothing is cut off or overlaps.
  2. Set the window 1280 pixels wide and zoom to 400%, or set the viewport 320 pixels wide in the developer tools. The content fits one column, with no sideways scrolling to read a line.
  3. Apply the spacing below as a user stylesheet. No text is clipped, and no control is covered.
  4. Turn the phone sideways and back. The page works both ways.

A failure looks like

  • Text is cut off or overlaps at 200%.
  • A line needs sideways scrolling at 320 pixels.
  • Spaced-out text spills out of a button or a card.
  • The page refuses to turn.
The four values WCAG 1.4.12 names, as a user stylesheet: line height 1.5, paragraph spacing 2, letter spacing 0.12 and word spacing 0.16 times the font size.
* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p {
  margin-bottom: 2em !important;
}

Back to the passes

Pass 4 of 7

One screen reader, one real task

Pick one pairing and finish the main task with the screen reader on. NVDA with Firefox or Chrome on Windows is free; VoiceOver with Safari comes with every Mac and iPhone; TalkBack with Chrome is on most Android phones. Once you know the commands, listen instead of looking.

The commands for one pass with each screen reader
To do thisNVDA, WindowsVoiceOver, MacVoiceOver, iPhoneTalkBack, Android
Turn it onCtrl+Alt+N, if the shortcut was set at installCommand+F5Ask Siri, or triple-click the side button once the Accessibility Shortcut is setHold both volume keys for a few seconds, once the shortcut is set
Stop speakingCtrlControlTwo-finger tapTwo-finger tap (TalkBack 9.1 and later)
Read on from hereNVDA+↓VO+ATwo-finger swipe downTwo-finger triple tap (9.1 and later)
Next item↓VO+→Swipe rightSwipe right
Next headingHVO+Command+HTurn the rotor to Headings, then swipe downChoose Headings as the reading control, then swipe down
List headings, links and landmarksNVDA+F7VO+U, the rotorRotate two fingers, the rotorSwipe up then down to change the reading control
ActivateEnterVO+SpaceDouble-tapDouble-tap

NVDA means the NVDA key: Insert by default, or Caps Lock if you choose it. VO means Control and Option together, or Caps Lock. Commands are from NVDA 2026.2’s quick reference, Apple’s VoiceOver guides, WebAIM’s VoiceOver article and Google’s TalkBack help.

Do this

  1. Load the page. The title is the first thing you hear.
  2. List the headings and the landmarks. They read like a table of contents.
  3. List the links. Each one makes sense on its own.
  4. Move to each control. You hear its name, its role and its state: “Filters, collapsed, button”.
  5. Fill in the form with a mistake. The error is announced, and the field says what is wrong.
  6. Save something, or add to the cart. The confirmation is announced without focus moving.

A failure looks like

  • A control is announced as “button” or “link” with no name, or not at all.
  • A state stays the same when you change it: still “collapsed” after it opens.
  • A message appears on screen and nothing is said.
  • A passage in another language is read with the wrong pronunciation.

Back to the passes

Pass 5 of 7

Color, contrast and motion

The analyzer measures text on solid colors. A person checks what it cannot: text over images, every state of every control, color used as the only signal, and anything that moves.

Do this

  1. Check text over images and gradients, and the hover, focus and selected states, in the contrast checker.
  2. View the page in grayscale, or through the color vision simulator. Nothing depends on hue alone.
  3. Switch to the dark theme, then to forced colors (a Windows contrast theme, or forced-colors emulation in Chrome’s Rendering panel). Controls keep their borders and their focus rings.
  4. Turn on reduced motion in the operating system, or emulate it in the same panel. Large animations stop or calm down.
  5. Watch for anything that starts moving by itself and lasts more than five seconds (it can be paused), sound that plays by itself for more than three seconds (it can be stopped), and flashing (never more than three flashes a second).

A failure looks like

  • A link, an error or a state is shown by color alone.
  • A focus ring vanishes in dark mode or under forced colors.
  • A carousel moves with no way to pause it.

Back to the passes

Pass 6 of 7

What only reading can tell

Rules can confirm that words exist; a reader confirms that they are right. This pass reads the words the other passes only located.

Do this

  1. Read every alt in its sentence: it says what the image is for. Text inside an image is repeated in real text.
  2. Watch the video with captions on, and with audio description where the picture carries information.
  3. Read every label, instruction and error as a first-time visitor. Each says what to do; an error says how to fix it.
  4. Check that related controls are grouped and named, and that common fields offer autofill.
  5. Try the submit that costs money or deletes data. It can be reviewed, confirmed or undone.
  6. Stay on a timed step. You are warned before time runs out, and can ask for more.

A failure looks like

  • An alt names the picture but not its point.
  • An error says “Invalid input” and nothing else.
  • A payment goes through on the first click, with no review.

Back to the passes

Pass 7 of 7

Write each finding so it can be fixed

A finding that someone can reproduce without asking you a question gets fixed. One that says “this feels wrong” gets argued about.

Do this

  1. Name the criterion, and link it. The checklist’s export does this for every flagged check.
  2. Write the steps from a fresh page load, including the state: the menu open, the error shown.
  3. Attach the evidence. The checklist keeps screenshots, and marks them up, on this device.
  4. Say what you tested with. Screen readers differ, so the browser, the assistive technology and their versions are part of the finding.
A finding, written so someone else can reproduce it
### 2.4.7 Focus Visible: no focus ring on the search button
Page: /search, with the filters panel open
Steps:
1. Load the page and press Tab until the search button is reached.
2. Look for the focus ring.
Expected: a visible ring around the button.
Actual: nothing changes; focus is invisible.
Tested with: Windows 11, Firefox (version from Help, About), keyboard only
Evidence: search-focus.png (the button circled)
Level: AA · Blocks: keyboard users

Back to the passes

After the passes

People with disabilities, in the loop

Every pass above is a stand-in. Someone who uses a screen reader for an afternoon learns whether things are announced, not whether the page is usable by a person who relies on one every day.

The W3C’s advice is to involve users with disabilities early, in informal sessions during development as well as in formal usability tests, because they find problems that a conformance check does not. Pay people for their time, and include people who use different assistive technology.

With this page

Keep the record

Where this comes from

Sources

Found a mistake? Write to us and we will correct it.