A11y roadmap
From the request to the build
Accessibility usually breaks at a handoff, not at a line of code. Someone asks for a component, a designer draws it, a requirement gets written, and the pieces that make it usable for everyone fall through the gaps between those steps.
This walks the same request through all five roles. Start with your own brief, or read the roadmap straight through.
Handoff overview
Pick your seat in the handoff and everything below narrows to that role. Choose Handoff overview for the whole pipeline.
Showing all five roles across every topic.
Describe your request
Paste a real content request, ticket or component idea. You get back the accessibility must‑haves for that specific thing, grouped by who owns them.
Nothing analyzed yet. The results will list the must‑haves for each role, with the WCAG criteria behind them.
The roadmap
Reusable team guidance for how each accessibility concern moves from request through validation. Use it for context, not as a separate checklist.
Four topics, each walked through the same handoff: the request arrives, the component gets designed, the requirement gets written, the code gets built, and the solution is validated.
Topic 1 of 4: Keyboard navigation
Topic 1 of 4
Keyboard navigation
Everything that works with a click has to work without one. Order, reachability and a focus ring you can actually see.
Why this matters
People using switch devices, screen readers, voice control or just a keyboard cannot use a control they cannot reach. A hover-only menu or an invisible focus ring silently removes the feature for them.
WCAG Success Criteria:2.1.1 Keyboard (opens in a new tab)2.4.3 Focus Order (opens in a new tab)2.4.7 Focus Visible (opens in a new tab)2.4.11 Focus Not Obscured (opens in a new tab)
Handoff pipeline
- Stakeholder
Say what the component must let someone do, not how they point at it.
Common gap
Requests written around hover reveals, drag interactions or "on mouseover" behavior with no stated alternative.
Passes on
A list of actions the component supports, described without a pointing device.
- Designer
Design the focus state as a real state, alongside default and hover.
Common gap
Focus styles left to the browser default and then removed by a reset, or a ring that disappears against the card background.
Passes on
A focus treatment with at least 3:1 contrast against adjacent colors, and a reading order the layout matches.
- UX
Write down the tab order, what Escape and Enter do, and where focus lands after an action.
Common gap
Requirements that describe the visual result but never say where focus goes when a panel opens or closes.
Passes on
An annotated order: which elements are stops, which are skipped, and the return point after any overlay closes.
- Developer
Use real buttons and links so order and activation come free, then style focus-visible.
Common gap
Click handlers on div and span, positive tabindex values, and outline:none with nothing replacing it.
Passes on
A component that can be operated end to end with Tab, Shift+Tab, Enter, Space and Escape.
- QA
Put the mouse down and run the whole flow on the keyboard, in both light and dark themes.
Common gap
Testing only with a pointer, so a pointer-only action or a missing focus ring ships unnoticed.
Passes on
A pass or fail per action: reachable, visibly focused, operable, and no trap. Failures go back to the developer, or to design when the focus treatment itself is missing.