Manual Accessibility Testing Checklist

The plain-language idea

Automated tools catch mechanically-checkable issues. This lesson is the practical companion: a short, concrete checklist a team can realistically run on every significant UI change, without needing deep specialist expertise, that catches a real chunk of what automation reliably misses. Three checks cover most of the ground:

• A keyboard-only pass. Unplug the mouse, or simply don't touch it. Can every interactive element be reached and operated? Is a visible focus indicator present at every step, not just some of them? Does the tab order follow a sensible sequence rather than jumping around unpredictably?
• A 200%-zoom / reflow check. Does the layout still work at significant browser zoom, with content reflowing into a single usable column rather than requiring horizontal scrolling to reach content? This is a real WCAG reflow requirement, not just a nice-to-have for low-vision users who routinely zoom to read comfortably.
• A "color alone" pass. Is a required-field indicator, an error state, or a status conveyed only by color, with no icon or text backup? This is a real, common failure for colorblind users — someone who can't distinguish red from green gets no signal at all if red is the only cue.

See it in a real thing: auditing a settings form

Settings form, before the checklist:
- Required fields marked with a red asterisk (color + shape — fine)
- Validation error shown as a red input border only (color alone — fails)
- Save button reachable by Tab, but focus ring suppressed by
  a global `outline: none` reset with no replacement (fails)
- At 200% zoom, the sidebar and form overlap and the sidebar's
  links become unreachable without horizontal scrolling (fails)

Each of these three failures is invisible to a typical visual review at 100% zoom with a mouse in hand — which is exactly the point of running the checklist deliberately rather than trusting that "it looked fine" during normal development.

What people usually miss

Watch out

• A missing focus indicator is one of the most common real failures, and it's invisible until you actually tab through the page. A global outline: none CSS reset with no replacement style is a frequent, silent culprit — it looks clean visually and breaks keyboard navigation completely.
• Reflow at 200% zoom is a genuine WCAG success criterion, not an informal best practice. Horizontal scrolling that traps content at high zoom is a real, checkable failure, and it's easy to miss because most manual testing happens at default zoom.
• The "relies on color alone" check is about presence of a backup signal, not about the exact contrast ratio. A red-bordered input with no icon or text fails this check even if the red itself is perfectly WCAG-contrast-compliant against its background — contrast and color-reliance are two separate failure modes.
• This checklist is deliberately not a full expert audit. The goal is catching the most common, highest-impact issues reliably on every change, run by any team member — not achieving the depth of a specialist accessibility audit on every single pull request.

Why this matters in interviews

"Walk me through how you'd manually check a new form for accessibility issues, without running any tooling" is a real, practical interview question, and naming these three specific checks — keyboard-only, zoom/reflow, color-alone — shows a candidate has an actual repeatable process, not just a vague notion of "testing accessibility."