Keyboard Navigation
Keyboard navigation means all interactive functionality on a web page can be operated using only a keyboard, without requiring a mouse, touch, or other pointing device. Tab moves focus between focusable elements, Enter and Space activate controls, and arrow keys navigate within composite widgets. Keyboard accessibility is a WCAG Level A requirement and a prerequisite for many assistive technologies.
§ 1 Definition
Keyboard navigation is the ability to access every interactive element on a web page using only the keyboard. This includes links, buttons, form controls, menus, tabs, sliders, dialogs, and custom widgets. The keyboard is the universal input method for assistive technology users: screen reader users navigate by keyboard, switch device users map single-switch inputs to keyboard equivalents, and people with motor disabilities rely on keyboard-only operation because fine-motor mouse control is unavailable. WCAG requires keyboard operability at Level A (2.1.1 Keyboard), meaning all functionality must be operable through a keyboard interface. This encompasses standard Tab/Shift+Tab navigation through focusable elements, Enter/Spacebar for activation, Escape to close dialogs and menus, and arrow keys for widget-specific navigation such as moving between radio buttons, list items, or tab panels.
§ 2 Tab order and visible focus indicators
The Tab key moves focus forward through interactive elements in the order they appear in the DOM. Shift+Tab moves backward. The order must be logical and predictable. A tab order that jumps erratically because of inappropriate tabindex values disorients keyboard users. Every focused element must have a visible focus indicator (often a visible outline or ring) so the user knows their current location. WCAG 2.2 tightened this requirement: the focus indicator must not be fully obscured by other elements (2.4.11 Focus Not Obscured, AA), and at the AAA level (2.4.13 Focus Appearance) it must be at least 2 CSS pixels thick with at least 3:1 contrast against the adjacent background.
§ 3 Roving tabindex and managed focus
Complex widgets such as listboxes, menus, tree views, and tab panels use roving tabindex, a pattern where only one element in the widget is in the Tab order (tabindex="0") while the others are removed from Tab order (tabindex="-1"). Arrow key presses move focus among child elements by updating their tabindex values programmatically via JavaScript. This prevents the user from having to Tab through every item in a long list to reach the next section. Managed focus is also crucial for single-page applications: when a dialog opens, focus must move into it; when it closes, focus must return to the element that triggered it. Failing to manage focus in SPAs is one of the most common accessibility defects in modern web applications.
§ 4 Common questions
- Q. What is the difference between tabindex="0" and tabindex="-1"?
- A. tabindex="0" adds an element to the natural Tab order. tabindex="-1" removes it from the Tab order but allows it to receive programmatic focus via JavaScript. Use tabindex="0" for elements that should be focusable by keyboard users. Use tabindex="-1" for elements that need to receive focus programmatically (such as when a dialog opens) but should not be in the Tab flow.
- Q. My custom component handles click events. Does it need keyboard support?
- A. Yes. If you use JavaScript to make a <div>, <span>, or custom element interactive, you must add keyboard event handlers that replicate the mouse behaviour. A button activated by onClick must also activate on Enter and Space. A drag-and-drop interface must have keyboard alternatives for reordering. WCAG 2.2 specifically added 2.5.7 Dragging Movements (AA), requiring a single-point alternative for any drag interaction.
- Every interactive element must be keyboard operable (WCAG Level A).
- Tab order must follow a logical DOM sequence.
- Every focusable element needs a visible focus indicator.
- Complex widgets require roving tabindex and focus management.
- SPAs must carefully manage focus when content changes without page reload.
Atomic Glue tests every interactive element on every project for full keyboard operability. We verify logical tab order, visible focus indicators, and proper focus management for SPAs and modals. Our Web Development services include keyboard accessibility as a standard deliverable. Get in touch.
Get in touchKeyboard navigation means all interactive functionality on a web page can be operated using only a keyboard, without requiring a mouse, touch, or other pointing device. Tab moves focus between focusable elements, Enter and Space activate controls, and arrow keys navigate within composite widgets. Keyboard accessibility is a WCAG Level A requirement and a prerequisite for many assistive technologies.
Category: Accessibility (also: Web Development, UX)
Author: Atomic Glue Team
## Definition
Keyboard navigation is the ability to access every interactive element on a web page using only the keyboard. This includes links, buttons, form controls, menus, tabs, sliders, dialogs, and custom widgets. The keyboard is the universal input method for assistive technology users: screen reader users navigate by keyboard, switch device users map single-switch inputs to keyboard equivalents, and people with motor disabilities rely on keyboard-only operation because fine-motor mouse control is unavailable. WCAG requires keyboard operability at Level A (2.1.1 Keyboard), meaning all functionality must be operable through a keyboard interface. This encompasses standard Tab/Shift+Tab navigation through focusable elements, Enter/Spacebar for activation, Escape to close dialogs and menus, and arrow keys for widget-specific navigation such as moving between radio buttons, list items, or tab panels.
## Tab order and visible focus indicators
The Tab key moves focus forward through interactive elements in the order they appear in the DOM. Shift+Tab moves backward. The order must be logical and predictable. A tab order that jumps erratically because of inappropriate tabindex values disorients keyboard users. Every focused element must have a visible focus indicator (often a visible outline or ring) so the user knows their current location. WCAG 2.2 tightened this requirement: the focus indicator must not be fully obscured by other elements (2.4.11 Focus Not Obscured, AA), and at the AAA level (2.4.13 Focus Appearance) it must be at least 2 CSS pixels thick with at least 3:1 contrast against the adjacent background.
## Roving tabindex and managed focus
Complex widgets such as listboxes, menus, tree views, and tab panels use roving tabindex, a pattern where only one element in the widget is in the Tab order (tabindex="0") while the others are removed from Tab order (tabindex="-1"). Arrow key presses move focus among child elements by updating their tabindex values programmatically via JavaScript. This prevents the user from having to Tab through every item in a long list to reach the next section. Managed focus is also crucial for single-page applications: when a dialog opens, focus must move into it; when it closes, focus must return to the element that triggered it. Failing to manage focus in SPAs is one of the most common accessibility defects in modern web applications.
## Common questions
Q: What is the difference between tabindex="0" and tabindex="-1"?
A: tabindex="0" adds an element to the natural Tab order. tabindex="-1" removes it from the Tab order but allows it to receive programmatic focus via JavaScript. Use tabindex="0" for elements that should be focusable by keyboard users. Use tabindex="-1" for elements that need to receive focus programmatically (such as when a dialog opens) but should not be in the Tab flow.
Q: My custom component handles click events. Does it need keyboard support?
A: Yes. If you use JavaScript to make a <div>, <span>, or custom element interactive, you must add keyboard event handlers that replicate the mouse behaviour. A button activated by onClick must also activate on Enter and Space. A drag-and-drop interface must have keyboard alternatives for reordering. WCAG 2.2 specifically added 2.5.7 Dragging Movements (AA), requiring a single-point alternative for any drag interaction.
## Key takeaways
- Every interactive element must be keyboard operable (WCAG Level A).
- Tab order must follow a logical DOM sequence.
- Every focusable element needs a visible focus indicator.
- Complex widgets require roving tabindex and focus management.
- SPAs must carefully manage focus when content changes without page reload.
## Related entries
- [Focus Management / Focus Indicator](atomicglue.co/glossary/focus-management-focus-indicator)
- [ARIA](atomicglue.co/glossary/aria)
- [Accessible Forms](atomicglue.co/glossary/accessible-forms)
- [WCAG (2.1, 2.2)](atomicglue.co/glossary/wcag)
Last updated July 2026. Permalink: atomicglue.co/glossary/keyboard-navigation