Manual Accessibility Testing — Screen Readers and Keyboard Nav

Automated tools clear approximately 30–40% of WCAG failures. The other 60–70% — keyboard traps, illogical tab order, screen reader announcements that make no sense, dynamic content that fails to notify, focus that disappears into the void — require a human. Manual accessibility testing is not a specialist discipline. It is a set of structured checks that any QA engineer can run. This lesson gives you the workflow.

Why manual testing is non-negotiable

An automated axe scan cannot determine whether a custom dropdown announces its options intelligibly to a screen reader. It cannot detect that Tab focus jumps from the form's second field to a button in the footer, skipping six interactive elements in between. It cannot tell you that the loading spinner that appears while data fetches is invisible to a screen reader user, who has no indication that something is happening.

These are the failures that block real users from completing real tasks. They are also the failures that never appear in automated reports.

The manual accessibility testing workflow

Step 1: Keyboard-only navigation

Unplug the mouse — or simply commit to not touching it. Navigate the entire page using:

• Tab — move forward through interactive elements
• Shift+Tab — move backward
• Enter — activate links and buttons
• Space — toggle checkboxes, activate buttons
• Escape — close modals, dismiss popups
• Arrow keys — navigate within components (dropdowns, radio groups, tabs, sliders)

What you are looking for:

• Every interactive element is reachable. If you cannot Tab to it, keyboard-only users cannot use it.
• Focus is always visible. You should always see a clear visual indicator of where keyboard focus is. If focus disappears or becomes invisible, file a bug.
• No keyboard traps. If you Tab into a component and cannot Tab back out, that is a Level A WCAG failure.
• Tab order is logical. Focus should move in reading order — left-to-right, top-to-bottom. Focus that teleports across the page is confusing even if every element is technically reachable.
• Modals trap focus correctly. When a modal opens, focus should move into it. You should not be able to Tab to content behind the modal. When it closes, focus should return to the trigger.

This test takes 10–15 minutes per page. It catches the majority of issues that automated tools miss.

Step 2: Zoom and resize

Zoom the browser to 200% (Ctrl/Cmd +), then to 400%. WCAG 1.4.4 requires content to be readable at 200% without loss of content or functionality — no horizontal scrolling required, no content clipped, no buttons disappearing.

Then use the browser's text-size setting (not page zoom) to increase font size to 200%. Does the layout reflow? Does text overlap with other elements? Does the line height grow enough that paragraphs remain readable?

Finally, disable CSS entirely (browser extensions can do this) and verify the page is still readable and navigable in source order. This exposes hidden elements, missing semantic structure, and navigation patterns that only work visually.

Step 3: Screen reader testing

Screen readers are the most revealing accessibility testing tool available. Spending 20 minutes with NVDA or VoiceOver tells you more about the real accessibility of a page than any automated report.

Which screen reader to use:

• VoiceOver (macOS): Cmd+F5 to start. Navigate with Ctrl+Option+Arrow. The fastest option for any tester on a Mac.
• NVDA (Windows): free from nvaccess.org. Navigate with Arrow keys; H for next heading, K for next link, F for next form field.
• VoiceOver (iOS): Settings → Accessibility → VoiceOver. Essential for mobile testing.
• TalkBack (Android): Settings → Accessibility → TalkBack. Swipe right to move forward, swipe up-then-right to activate.

What to do during the test:

1. Navigate to the page and listen to the first few announcements. Is the page title announced? Is there a meaningful heading structure (H1 first, logical hierarchy)?
2. Move to the first form. Are field labels announced? Are placeholder-only fields announced as labelled?
3. Activate a button by pressing Enter or Space. Is the button's purpose announced? Does activation confirm the result?
4. If the page has dynamic content (a search result, a loading state, a success toast), trigger it and listen. Is the change announced?
5. Try to complete a complete user journey — login, search, purchase — with your eyes closed for the last stage. Where did you get lost?

Common screen reader bugs:

• Icon buttons announced as "button" with no purpose ("close", "edit", "delete" not announced)
• Form fields announced as "edit blank" because placeholder is the only "label"
• Modal opens but focus stays on the trigger — user hears nothing has changed
• Live region updates (search results, basket count) not announced because aria-live is absent
• Custom widgets (accordions, tabs, carousels) operable with mouse but silent or broken with keyboard/screen reader

For a deeper introduction to screen readers, the Screen readers and assistive technology basics lesson in the Manual Software Testing course covers VoiceOver and NVDA in detail.

Step 4: Cognitive and motion review

Cognitive accessibility is the hardest to test systematically but covers a significant proportion of users. A quick structured review:

• Language clarity: is the primary content written at a reading level appropriate to the audience? Are technical terms explained or avoided?
• Navigation consistency: do navigation elements appear in the same location and order on every page?
• Time limits: if any session or task has a time limit, is there a warning with sufficient advance notice, and a way to extend it?
• Motion and animation: open the page on a device or OS with "Reduce Motion" enabled (macOS: System Preferences → Accessibility → Display → Reduce Motion). Does the application respect prefers-reduced-motion? Animations and parallax effects should be suppressed.
• Error recovery: when a form error occurs, is it announced to screen readers? Does it describe the problem and how to fix it, not just "an error occurred"?

⚠️ Common mistakes

• Using a screen reader with eyes open for the whole test. The point of screen reader testing is to experience the page as a blind user does. At least part of the test — navigating a key flow — should be done eyes closed. It is the only way to feel the real impact of the issues.
• Only running the automated scan before filing a bug. An axe finding tells you something is wrong. The screen reader tells you what the user experiences. File bugs with both: the technical criterion and the user impact.
• Testing accessibility only at launch. Dynamic content, new components, and framework upgrades all introduce regression risk. Accessibility testing belongs in the definition of done for every feature, not just the initial release.

🎯 Practice task

Run a complete manual accessibility test on one page — your bank's login, a checkout flow, a form-heavy admin page.

1. Complete steps 1–4 from the workflow above, spending 5–10 minutes on each.
2. Write a bug report for the most impactful finding you discover. Include: the WCAG success criterion and level, the affected user group, the reproduction steps, and what you heard (or did not hear) in the screen reader.
3. Estimate how long this full manual test took. That is the cost of manual accessibility testing per page. Compare it to the cost of a user who cannot complete the flow at all.

The Manual Software Testing course covers individual manual checks in greater depth — keyboard testing, contrast checking, heading hierarchy, and image alt text — for engineers who want to build a deeper manual testing practice.