The two checks that catch a huge share of real bugs.
Two manual checks catch most of what actually reaches production: tabbing through the page with no mouse, and listening to how a screen reader announces it. Neither needs special tooling. A static screenshot can't catch either one, since both depend on how the page actually behaves, not how it looks.
| Key | Expected behavior |
|---|---|
| Tab | Moves focus to the next interactive element, in a sensible order |
| Shift+Tab | Moves focus backward, same order in reverse |
| Enter / Space | Activates the focused button, link, or checkbox |
| Esc | Closes the open modal, no mouse required |
| Arrow keys | Move within menus, radio groups, and dropdowns |
The full keyboard testing quick-reference card is in Guide 2, Section 07.
Unplug the mouse and tab through the page for these. Turn on a screen reader (VoiceOver on Mac, Narrator on Windows, both free) and listen for how it announces each element.
I want to test this like I only have a keyboard and can't see the screen, not like I'm running an automated scanner. Feature or screen: [describe what it is and what a user does on it] Walk me through it step by step as if I've unplugged my mouse and I'm listening to a screen reader instead of looking at the page. At each step, tell me exactly what I should do (Tab, Enter, Escape, arrow keys) and exactly what correct behavior sounds and feels like, not what it looks like, since I'm not looking. Call out specifically: anywhere focus could get stranded or trapped, anywhere the only cue that something happened is visual, and anywhere a sighted user would rely on hovering to find something. Don't tell me to "run an accessibility scanner." I want the manual walk- through only.
AI's real value here: translating a dense WCAG success criterion into "here's what to actually click and check."
Run it on a real page.
Pick any form on your own product (or a public site). Run the five checks in the table above by hand. Then use The Blind Pass prompt to walk through one specific component on that page, and compare it to what you found manually.
The takeaways:
- The uncomfortable fact: most accessibility bugs are invisible to mouse-and-eyes testing. You'll never personally hit a focus trap because your eyes route around it automatically. The bug is only real to someone who can't do that
- The technique: unplug the mouse. Follow only what the keyboard and the screen reader tell you
- Where AI fits: it translates a dense WCAG criterion into concrete steps, and the Blind Pass prompt walks any component keyboard-only and screen-reader-only, calling out where focus could strand or the only cue is visual
Why it works: "put yourself in someone else's shoes" here isn't an empathy exercise. It's a mechanical, repeatable procedure, and that constraint surfaces the bug your normal workflow was structurally incapable of finding.
Check yourself: pick a form you use daily, something on your own site or a tool you already have open. Tab through it right now with your mouse untouched. Did you get stuck anywhere? Could you tell what was focused without looking? If you hesitated even once, you just found a real bug the mouse-and-eyes pass would never catch.
This isn't hypothetical.
Every technique in this module was run against a real site: the 16+ findings above, remediated using exactly this manual-first approach before any automated tooling. Guide 2 (The Manual Tester's AI Toolkit) has the full prompt library, 27 more prompts beyond this one.
See the full AI Toolkit →The five checks that catch most real accessibility bugs
A prompt that walks any component keyboard-only, screen-reader-only
Why static scanners miss dynamic-behavior issues these checks catch
Regression, Mobile & Stakeholder Communication.
- Prioritizing what to re-test based on change scope and risk
- Briefing AI on mobile-specific failure modes
- Translating findings into language stakeholders act on