Keyboard Navigation

Keyboard navigation

Everything a mouse can do, a keyboard must do: this is the baseline for users who cannot use a pointer (motor disabilities, screen-reader users, power users). Keyboard access is also the foundation screen readers build on, so getting it right serves multiple needs at once.

Method

1. Make every interactive element focusable and operable. Native interactive elements (<button>, <a>, form controls) are keyboard-operable for free; custom ones (see aria-usage) need tabindex="0" plus key handlers (Enter/Space activate buttons, arrow keys navigate composite widgets). If a mouse user can click it, a keyboard user must be able to reach and activate it: a click handler on a <div> with no keyboard equivalent is the classic exclusion.
2. Keep focus order logical. Tab order follows the visual/reading order (top to bottom, left to right in most locales): driven by DOM order, not by positive tabindex values (which create maintenance nightmares and confusing jumps). If the visual order and DOM order diverge (CSS reordering), fix the DOM order or the layout; a tab order that jumps around the screen disorients.
3. Never trap focus unintentionally. Focus must be able to leave every component via keyboard; a widget that captures Tab and never releases it strands keyboard users (a real, common bug in custom modals and embeds). The one intentional trap is a modal dialog, which should trap focus within it while open and return focus on close (see focus-management): deliberate and reversible, never accidental and permanent.
4. Provide skip links. A "skip to main content" link as the first focusable element lets keyboard and screen-reader users bypass repeated navigation (tabbing through fifty nav links on every page is exhausting): visible on focus, jumping focus to the main content. This small addition dramatically improves the experience for keyboard users on content-heavy sites.
5. Use roving tabindex for composite widgets. In widgets like menus, toolbars, and grids, the whole widget is one tab stop, and arrow keys move within it (roving tabindex: one child has tabindex="0", others tabindex="-1", updated as focus moves): so users tab past the widget quickly and explore inside with arrows, matching the ARIA patterns (see aria-usage). Making every menu item a tab stop makes navigation tedious.
6. Make focus visible, always. A clear visible focus indicator (never outline: none without a replacement: see focus-management) so keyboard users can see where they are: an interface that is keyboard-operable but shows no focus is unusable, because the user is navigating blind. Style the focus indicator to be obvious, honoring :focus-visible.

Boundaries

• Keyboard navigation is necessary but not sufficient for accessibility; it pairs with screen-reader semantics (see screen-reader-testing, aria-usage) and visible focus (see focus-management). All three together make an interface accessible.
• Test by actually navigating with only the keyboard (unplug the mouse): automated tools miss focus-order and trap issues that only manual keyboard testing reveals.
• Custom keyboard shortcuts (single-key access) can conflict with assistive tech and browser shortcuts; follow established patterns and make custom shortcuts configurable or scoped (see the shortcut cautions in mobile-input-ux's desktop cousin).