UX Glossary · K
Keyboard navigation
Operating an interface entirely by keyboard, which is both an accessibility requirement and a power-user path.
Keyboard navigation means every interactive element can be reached and operated without a pointing device: Tab to move forward, Shift+Tab back, Enter and Space to activate, arrow keys within components such as menus and radio groups.
WCAG success criterion 2.1.1 requires all functionality to be keyboard operable, and 2.1.2 requires that focus can always be moved away again, the “no keyboard trap” rule.
Who depends on it
Screen reader users, people with motor impairments who cannot use a mouse precisely, people using switch devices or voice control that maps to keyboard events, and anyone with a temporary injury.
It is also the interface power users prefer. Keyboard operability is not a compliance tax, it is the same work that makes an application fast for people who use it all day.
The three common failures
Custom controls that are not focusable. A div styled as a button is invisible to Tab.
Using real button and a elements solves most of this for free.
Focus indicators removed. outline: none with nothing in its place makes an interface
navigable but impossible to follow. WCAG 2.4.7 requires focus to be visible.
Illogical focus order. Visual order and DOM order diverging, usually because CSS moved things, so Tab jumps around the page unpredictably.
In practice
Put the mouse away and Tab through a page. Failures announce themselves in about a minute.