Accessibility changes product behavior
Keyboard order, focus restoration, error announcements, labels, contrast, reduced motion, zoom, and touch targets are not decorative checks. They define how people operate the product.
If these decisions appear only after development, teams are forced to retrofit interaction models that were never designed to support them.
Write acceptance criteria people can observe
A useful accessibility requirement describes what a person can do and what evidence proves it. For a dialog, define how focus enters, how it is contained, which keys close it, and where focus returns afterward.
- Every control has an accessible name.
- The complete journey works with a keyboard.
- Errors are associated with their fields and announced.
- Content remains usable at 200% zoom and narrow widths.
Automate checks without outsourcing judgment
Static analysis and browser automation catch valuable classes of failure, but they cannot decide whether labels are clear, reading order is sensible, or a workflow is understandable.
The strongest QA combines automated checks with short manual journeys performed against the same product contract.