Test keyboard, mobile and error recovery tasks
Check a buying journey using keyboard navigation, a narrow phone layout and an intentional form error. The expected behavior includes visible focus, understandable selection and recovery without losing valid input. Record the exact failed task so its repair can be retested; these few checks do not establish full accessibility conformance.
Worked example — illustrative data.
| Task | Expected behavior | Evidence to record |
|---|---|---|
| Reach a product using keyboard | Visible focus and usable navigation | Keys, stopping point and screenshot |
| Choose a variant on a phone | Labels and selected state stay readable | Device, orientation and selection |
| Submit an incomplete enquiry | Specific error and preserved valid input | Field message and recovery path |
| Open and close a dialog | Focus moves sensibly and returns | Entry, dismissal and next focus |
Choose one representative journey and complete it without a mouse before repeating it on a phone. Write down the exact point of confusion and what information was missing. Include zoom and narrow layouts where the task could lose a control. Use the W3C criteria to investigate a failure rather than declaring a whole site compliant after these few tasks. Retest the same failed step after the fix.
A visible error may remain undiscoverable to assistive technology
A form may show an error visually while a keyboard or screen-reader user cannot discover it. Check how the message is associated with the relevant control and how focus helps recovery.
Prioritize defects that prevent selection, submission or recovery. Keep broader accessibility review separate from this focused usability sheet, with its own scope and evidence.
Continue with Guides for stores, software teams and local businesses, Website accessibility reviews and remediation and Build a usable product size guide.
For keyboard, focus and error recovery, see the W3C WCAG quick reference.