Start with the Path, Not the Checklist
Accessibility work goes better when teams understand the path early instead of treating WCAG like a last-minute checklist.
Tommy Truong
“Make It Accessible” Is Not a Requirement
“Make it accessible” is a good intention, but it is not enough for a team to build, test, accept, or review. Useful accessibility requirements describe the behavior people need.
Good Accessibility Requirements Prevent Rework
Accessibility requirements do not need to be complicated. They need to be clear enough that the team knows what to build, test, accept, and review.
QA Keyboard Check
A practical no-mouse QA checklist for checking keyboard access, visible focus, focus order, traps, dialogs, forms, errors, and common interactive controls.
Keyboard-Only Navigation
A practical Field Guide page about checking whether people can move through screens, controls, menus, dialogs, and forms without using a mouse.
Forms and Labels
A practical Field Guide page about labels, instructions, grouping, and required fields that help forms feel usable instead of like guessing games.
Form Review Checklist
A practical checklist for reviewing labels, instructions, required fields, errors, grouping, and recovery before a form goes to accessibility review.
Focus Visible and Focus Order
A practical Field Guide page about making keyboard focus visible, predictable, and ordered so people do not lose their place on the page.
Error Messages and Recovery
A practical Field Guide page about writing and placing error messages so users can understand what went wrong and recover without guessing.
WCAG 2.1 A/AA Map
A plain-language orientation map for the 50 WCAG 2.1 Level A and AA success criteria, grouped by principle.
