Why keyboard navigation matters

Keyboard support isn't just for power users. People with temporary or permanent motor impairments, users of assistive technology, and anyone who prefers shortcuts all depend on the ability to move through an app without a mouse. A well-designed keyboard experience benefits everyone, so building a solid navigation strategy from the start is worth the effort.

Focus and the tab order

Focus is the element currently receiving keyboard input—a field, checkbox, button, or link. The focused element also receives clipboard content when pasting. Users move focus with TAB to go forward and SHIFT + TAB to go backward. A visible focus ring, styled differently across browsers, typically marks the current position. The sequence of forward and backward movement through interactive elements is the tab order.

Interactive HTML elements—text fields, buttons, and select lists—are implicitly focusable. They're automatically inserted into the tab order in their position in the DOM and come with built-in keyboard event handling. Non-interactive elements like paragraphs and divs aren't implicitly focusable because users generally don't need to interact with them.

A smooth keyboard experience depends on a logical tab order. Keep two principles in mind when reviewing your layout:

  1. Arrange elements in the DOM in the order they should receive focus
  2. Ensure offscreen content that shouldn't receive focus isn't visible to the tab order

Keep DOM order aligned with visual order

To verify your application's tab order is intuitive, tab through the page. Focus should generally track reading order, moving left to right and top to bottom.

If focus order feels wrong, rearrange the DOM elements so the tab order matches what the user sees. If you want an element to appear earlier on screen, move it earlier in the DOM rather than using CSS to shift its visual position.

Consider a floated button that makes the visual layout different from the source order:

Don't

<button style="float: right">Kiwi</button>
<button>Peach</button>
<button>Coconut</button>

The CSS float on the kiwi button creates a focus order that doesn't match the visual layout.

Do

<button>Peach</button>
<button>Coconut</button>
<button>Kiwi</button>

Place HTML elements in the DOM in the order the tab order should follow.

When you reposition elements purely with CSS, check that you haven't broken the tab order. In this case, removing the inline style and moving the kiwi button after Coconut in the markup fixes the problem.

Hide offscreen interactive content properly

Sometimes elements need to exist in the DOM but shouldn't be focusable while they're hidden. For example, a responsive sidebar navigation that opens on a button click—users shouldn't tab into the navigation while it's closed.

To remove an interactive element from the tab order, use either:

  • display: none
  • visibility: hidden

To restore the element to the tab order when it becomes visible, switch to:

  • display: block
  • visibility: visible

A quick habit worth building

For users who rely on the keyboard almost exclusively, a logical tab order is essential. A useful habit: tab through your application before every publish to catch focus order issues before they reach users.