Keyboard Navigation Patterns

Tab Order

When a user presses Tab, focus moves to the next interactive element in DOM order. This is the default behavior and it works well when your HTML structure matches the visual layout. Links, buttons, inputs, selects, and textareas are all natively focusable. They appear in the tab sequence without any extra work.

Problems arise when developers try to override this natural order. The tabindex attribute accepts any integer, but positive values (tabindex="1", tabindex="2", etc.) break the natural flow. Elements with positive tabindex values receive focus before everything else on the page, regardless of their position in the DOM. This creates an unpredictable, disorienting experience, especially on pages where multiple developers have added conflicting tabindex values over time.

A common source of confusion is CSS visual reordering. Properties like flex-direction: row-reverse, order, and CSS Grid placement can make elements appear in a different sequence than their DOM position. But tab order follows the DOM, not the visual layout. The result: it looks different, but tabs the same.

<!-- Visual order: Third, First, Second (due to CSS order property) -->
<!-- Tab order: First, Second, Third (follows DOM) -->

<div style="display: flex;">
  <button style="order: 2;">First</button>
  <button style="order: 3;">Second</button>
  <button style="order: 1;">Third</button>
</div>

<!-- Users see "Third, First, Second" visually -->
<!-- But pressing Tab goes: First → Second → Third -->
<!-- This disconnect confuses keyboard users -->

The fix is simple: make DOM order match visual order. If you need a different visual arrangement, restructure the HTML rather than relying on CSS ordering properties. When DOM and visual order align, keyboard navigation becomes predictable and intuitive for all users.

For dynamic interfaces where elements appear or disappear (modals, accordions, dropdown menus), manage focus explicitly using tabindex="-1" and element.focus(). This ensures focus moves logically when the interface changes. See the Focus Management guide for detailed patterns on trapping and restoring focus.

Arrow Key Patterns

Composite widgets (components containing multiple interactive children) use arrow keys for internal navigation instead of Tab. This follows the principle that Tab moves between widgets while arrow keys move within a widget. This pattern is sometimes called "roving tabindex" or "active descendant" depending on the implementation approach.

The direction of arrow key navigation depends on the widget's orientation. Horizontal widgets like tab bars, toolbars, and pagination controls use ← and → arrows. Vertical widgets like menus, listboxes, and tree views use ↑ and ↓ arrows. Grid-based widgets (data tables, spreadsheets, calendars) support navigation on both axes.

The ARIA Authoring Practices Guide (APG) defines the expected keyboard interaction for each widget type. Following these patterns ensures consistency. Screen reader users learn a pattern once and expect it to work the same way everywhere. Deviating from established patterns creates confusion, even if your custom approach seems "simpler."

When implementing these patterns, choose between roving tabindex (moving tabindex="0" between children) and aria-activedescendant (keeping focus on the container and updating which child is "active"). Roving tabindex is simpler and works universally. aria-activedescendant requires less DOM manipulation but has inconsistent screen reader support in some contexts. The ARIA APG documents both approaches for each pattern.

Common Keyboard Shortcuts

Beyond tab and arrow navigation, several keys have conventional meanings in web interfaces. Users expect these shortcuts to work consistently across your application and across different websites. Violating these conventions (like making Escape do something other than "close") breaks the mental model that keyboard users rely on.

When building custom application-level shortcuts (like Ctrl+K for a command palette or / to focus search), be careful not to conflict with browser or screen reader shortcuts. Always provide a way to discover available shortcuts (a help modal on ? is a common pattern) and never make shortcuts the only way to perform an action.

Screen Reader Keyboard Shortcuts

Screen readers add their own layer of keyboard interaction on top of the browser. When a screen reader is active, most keypresses are intercepted for navigation rather than passed to the web page. This is called "browse mode" or "virtual cursor mode." Understanding these shortcuts helps you appreciate why semantic HTML matters: it's what screen reader navigation keys target.

The following table shows the most common single-key navigation shortcuts for jumping between elements. These only work in browse mode (not forms mode / focus mode). When focus enters a form control, the screen reader switches to pass-through mode so keystrokes go to the input field.

Focus Indicators

A keyboard user's cursor is the focus indicator. Without a visible focus ring, keyboard users cannot tell where they are on the page. It's the equivalent of hiding the mouse cursor. WCAG 2.4.7 requires a visible focus indicator for all interactive elements, and WCAG 2.4.11 (level AAA, but best practice) specifies minimum size and contrast requirements.

The most important rule: never remove outlines without providing a replacement. The infamous outline: none or *:focus { outline: 0 } in a CSS reset removes the only visual cue keyboard users have. If the default browser outline doesn't match your design, replace it with a custom focus style: a box shadow, border change, background change, or combination.

Use :focus-visible instead of :focus to show indicators only for keyboard navigation, not mouse clicks. Browsers apply :focus-visible heuristically: it activates on Tab navigation and programmatic focus, but not on click. This gives you keyboard-only indicators without the visual noise that frustrates mouse users.

Focus indicators must have a minimum contrast ratio of 3:1 against adjacent colors. This means a thin light-blue outline on a white background might not be sufficient. Test your focus styles against both the background and surrounding content to ensure visibility.

For complete coverage of focus management patterns (trapping focus in modals, restoring focus after dismissal, managing focus in dynamic content, and handling focus for route changes in SPAs) see the dedicated Focus Management guide.

Testing Keyboard Accessibility with Speakable

Speakable's CLI provides structural analysis that complements manual keyboard testing. While nothing replaces actually pressing Tab through your interface, Speakable can quickly inventory all interactive elements, verify they have accessible names, and inspect their focusable properties. This catches many common issues (unlabeled buttons, missing roles, elements that should be focusable but aren't) before you even start manual testing.

Audit interactive elements

Use audit mode to get a complete inventory of interactive elements and their accessibility properties:

speakable page.html -f audit

This shows the interactive element inventory: every button, link, input, and custom control, along with whether each has an accessible name, correct role, and valid keyboard interaction.

Check announcements for interactive elements

Verify that screen readers would announce meaningful information when focus lands on interactive controls:

speakable page.html -f text -s nvda --selector "button, a, input"

This filters output to only show what NVDA would announce for buttons, links, and inputs. If any element produces a bare "button" or "link" announcement with no name, you've found an accessibility issue.

Inspect focusable properties

JSON output gives you structured data about every element's accessibility tree properties, useful for scripting and CI integration:

speakable page.html -f json