Glossary / Keyboard navigation

Keyboard navigation

Keyboard navigation means every interactive function can be operated using a keyboard or keyboard-like input, without requiring precise pointer movement. It supports people who are blind, have motor disabilities, use switch devices, or simply prefer a keyboard. Accessible keyboard behavior follows familiar browser conventions: Tab moves among controls, Shift+Tab reverses, Enter activates links, and Space commonly activates buttons. Composite widgets may use arrow keys internally, but should not disrupt normal document navigation.

What to know

• WCAG 2.2 SC 2.1.1 requires keyboard-operable functionality, except where the underlying function inherently depends on a path-based movement (for example freehand drawing).
• SC 2.1.2 prohibits keyboard traps: users must be able to move focus away using the keyboard. If a nonstandard exit exists, it must be discoverable.
• Focus order should preserve meaning and operability; DOM order is the reliable default. Positive tabindex values create fragile custom ordering and should generally be avoided.
• tabindex="0" adds an element to sequential focus; tabindex="-1" permits programmatic focus but removes it from sequential tab order. Native interactive elements are naturally focusable.
• In composite widgets such as menus, tabs, grids, and radio groups, roving tabindex or aria-activedescendant may keep one Tab stop while arrow keys move within the widget.
• Keyboard access must include dialogs, menus, drag alternatives, custom editors, media controls, and content revealed on hover.

Implementation and testing

Use native controls; maintain a visible focus indicator; ensure sticky headers, overlays, and cookie banners do not hide the focused element. Do not use outline: none without a sufficiently visible replacement. Test the full journey with keyboard only: Tab/Shift+Tab, Enter, Space, Escape, arrow keys where the widget pattern calls for them, and focus return after closing overlays. Test that keyboard users can dismiss or bypass content and that shortcut keys do not conflict with assistive technology. Avoid keyboard shortcuts triggered by a single character unless users can turn them off, remap them, or limit them to focused components.

Interview questions

1. How do Tab order and arrow-key navigation differ? Tab usually moves between page-level controls; arrow keys may move within a composite widget according to its pattern.
2. Why avoid positive tabindex? It decouples focus order from DOM order and becomes difficult to maintain as content changes.
3. What is a keyboard trap? A keyboard user can enter a component but cannot leave it through expected or documented keyboard operation.
4. How do you test a modal? Open it from keyboard, verify focus enters appropriately, stays within the modal when modal behavior requires it, Escape/close works, and focus returns to the opener.
5. What is the best default focus order? Logical DOM order, with CSS layout preserving rather than contradicting it.

References

• WCAG 2.2 Keyboard
• WCAG 2.2 No Keyboard Trap