FSD Frontend System Design

Part IV — The Reach · Lesson 8.2

Keyboard Accessibility

In one lineEverything clickable must be reachable by Tab, activatable by Enter or Space, and visibly focused.

Where you've seen itA dialog that opens fine, then leaves Tab cycling through the page behind it while Escape does nothing.

  • Time16 min
  • DiagramTab order path over a layout + the key contract per widget
  • Chapter8 · Accessibility

Diagram

diagram
TAB ORDER FOLLOWS THE DOM, NOT THE CSS

  ┌─────────────────────────────────────────────┐
  │ [1 Skip to content]                         │
  │ ┌──────────┐   ┌───────────────────────┐    │
  │ │ [2 Logo] │   │ [3 Search] [4 Sign in]│    │
  │ └──────────┘   └───────────────────────┘    │
  │ ┌─────────────────────┐  ┌───────────────┐  │
  │ │ main                │  │ sidebar       │  │
  │ │  [5 Filter]         │  │  [7 Related]  │  │
  │ │  [6 Buy now]        │  │               │  │
  │ └─────────────────────┘  └───────────────┘  │
  └─────────────────────────────────────────────┘

  If CSS (order, flex-direction: row-reverse, grid placement)
  moves things visually, the tab order no longer matches what
  the user sees. Fix the DOM, not the tabindex.
diagram
THE KEY CONTRACT — what users expect, per widget

  button          Enter, Space          activate
  link            Enter                 navigate
  checkbox        Space                 toggle
  radio group     Arrows                move + select (one tab stop)
  select / menu   Arrows, Home, End     move · Enter select · Esc close
  dialog          Esc                   close, focus returns to trigger
  tabs            Arrows                switch · Tab moves OUT of the set
  tree/grid       Arrows                two-dimensional movement

  Build a custom widget and you inherit ALL of its expected keys.
diagram
tabindex — three values, two of them fine

   0   in the natural tab order         ✓ custom interactive elements
  -1   focusable by script only         ✓ dialogs, error summaries,
                                          roving-tabindex items
  >0   jumps the queue                  ✗ never — breaks the whole page

How it works

  1. Use <button> and <a href>. They're focusable, activatable, and announced correctly with zero code.
  2. If you must use a div, you owe it role, tabindex="0", and both keydown handlers — Enter and Space for buttons.
  3. Never remove focus outlines. Restyle them instead; :focus-visible shows a ring for keyboard users without showing it on mouse clicks.
  4. Add a skip link as the first focusable element so keyboard users can bypass the nav.
  5. Use roving tabindex for composite widgets (toolbars, radio groups, tabs): one tab stop for the group, arrows to move within it.
css
/* keep the ring for keyboard users; hide it for mouse clicks */
:focus-visible { outline: 2px solid var(--accent); outline-offset: 3px; }

Trade-offs

DoDon't
<button onClick><div onClick>
:focus-visible restyleoutline: none
Roving tabindex for groups12 tab stops in a toolbar
DOM order = visual ordertabindex="5" to patch order

Interview angle

"How do you test keyboard accessibility?"

  • Put the mouse away and Tab through the whole flow: everything interactive must be reachable, activatable, and visibly focused.
  • Check the order matches the visual layout, since CSS can reorder without changing the DOM.
  • For each custom widget, verify the expected keys — Escape on dialogs and arrows on composite widgets are the usual gaps.

Recap

  • Reachable, activatable, visible — the three keyboard requirements.
  • Tab order comes from the DOM; positive tabindex is always the wrong fix.
  • Custom widgets inherit the full key contract of the thing they imitate.