Accessibility journey lab
Six journeys to test before release
Run these on the assembled page. Automated checks are useful for detectable violations; human interaction reveals whether the journey actually works.
Understand the page
- Likely barrier
- Heading structure, landmarks or link text do not communicate purpose
- Test
- Navigate headings and landmarks; read links out of surrounding context
- Repair
- Use native structure and descriptive text that matches the visible hierarchy
Navigate without a pointer
- Likely barrier
- Controls are unreachable, focus disappears or order conflicts with the layout
- Test
- Complete the primary task using keyboard input only
- Repair
- Use native interactive elements, logical order and visible focus
Complete and correct a form
- Likely barrier
- Labels, requirements and errors are visual but not programmatically associated
- Test
- Submit empty and invalid values, then locate and fix every error
- Repair
- Associate names, instructions and errors; preserve entered values and move focus intentionally
Use dynamic UI
- Likely barrier
- Dialogs, menus, tabs or updates lack correct focus and state behavior
- Test
- Open, operate and close each widget by keyboard; inspect its accessible name and state
- Repair
- Prefer native elements or follow the relevant WAI-ARIA interaction pattern completely
Read at different perception settings
- Likely barrier
- Zoom, text spacing, contrast or narrow layout hides content and controls
- Test
- Zoom and enlarge text; inspect reflow and essential contrast
- Repair
- Allow responsive reflow, sufficient contrast and flexible content sizing
Receive status and recover
- Likely barrier
- Loading, success and error changes are visible but never announced or remain ambiguous
- Test
- Trigger slow, successful and failed actions with assistive technology
- Repair
- Expose concise status, retain context and provide a clear recovery action
Why generated semantics need review
An ARIA attribute is not evidence that the interaction works
Generated components may add roles while omitting keyboard behavior, focus management or state updates. Incorrect ARIA can make a native interaction less understandable. Start with the semantic HTML element that already matches the behavior, and use a custom widget only when the product genuinely needs it.
Accessibility also includes content and error recovery. A perfectly named button cannot rescue an unclear task, a destructive action without confirmation or a timeout that discards entered information.
- Test the critical journey, not isolated components only
- Include disabled, loading, empty, invalid and error states
- Keep automated findings separate from human-verified usability
- Retest after layout and interaction changes
Decision matrix
Match tools to the question they can answer
No single tool establishes accessibility. Combine fast automation with browser inspection and representative human use.
| Method | Good at | Cannot establish alone | Evidence |
|---|---|---|---|
| Automated rules | Missing names, invalid attributes and some contrast issues | Comprehension, correct focus flow or complete conformance | Repeatable violations tied to elements |
| Keyboard review | Reachability, order, focus and operability | Screen-reader output or visual perception | Recorded completion and blockers |
| Accessibility tree | Computed roles, names, states and relationships | Whether the content makes sense | Observed semantic contract |
| Zoom and responsive review | Reflow, clipping and enlarged-text behavior | All visual needs or device combinations | Viewport, settings and screenshots |
| Assistive-technology testing | Real announcements, navigation and recovery | Every user’s experience | Named environment, journey and outcome |
Applied example
Accessibility failure: a beautiful custom select
A generated pricing form uses a styled div as a plan selector. It responds to clicks but is skipped by Tab, has no accessible name and does not expose the selected value.
- A screenshot and mouse-only demo show no failure.
- Keyboard and assistive-technology users cannot perceive or operate the choice.
- Adding only a role would still leave keyboard behavior and state management incomplete.
- A native select may satisfy the requirement with less code and a more reliable interaction contract.
Plain answers
Accessibility questions
Can an automated score prove accessibility?+
No. Automation catches a valuable subset of issues. Complete conformance and practical usability require scoped human evaluation.
Does semantic HTML matter if the page looks correct?+
Yes. Semantics provide structure, names and behavior used by browsers and assistive technology, and often reduce the amount of custom code required.
Should accessibility wait until the design is finished?+
No. Requirements such as focus order, error recovery and content structure affect component and journey design; late fixes are usually more expensive.