accessibility-validation-planner

Define the pages, flows, and states in scope, then plan checks across semantics, keyboard, focus, screen readers, zoom and reflow, contrast, motion, and automated tools. Assign each check a method, evidence type, and priority, and finish with release gates separating blockers from accepted risks.

A thorough checklist covers landmarks and headings, accessible names, keyboard-only task completion, focus visibility and restoration, screen-reader announcements, contrast and non-color cues, zoom and reflow, reduced motion, and automated scans with their known blind spots.

No. Tools like axe-based scans and accessibility linters catch only a subset of issues, so the plan records tool blind spots and reserves manual keyboard, focus, and screen-reader verification for final release gates.

Choose representative assistive-technology and browser combinations appropriate to your project's audience, then validate that equivalent information and control states are conveyed rather than requiring identical phrasing across every screen reader.

Skip it when you already have a specific failing accessibility issue needing a direct code fix, when the request is purely visual polish, or when you need a legal compliance opinion rather than a technical validation plan.