Keyboard navigation

Keyboard navigation is the ability to reach, operate and leave every interactive element of an interface using only a keyboard, with a clearly visible indication of where the input currently goes. In accessibility it is a foundational requirement, because many people cannot use a mouse or touch screen reliably.

Keyboard users include people with motor impairments, people who are blind and use a screen reader, people using switch devices or voice control that emulate keystrokes, and power users who simply work faster without a pointer. If an interface fails keyboard navigation, all of these groups are blocked at once.

How keyboard focus moves through an interface

Keyboard navigation relies on focus, the state that marks the one element currently receiving keyboard input. Pressing Tab moves focus to the next focusable element and Shift+Tab moves it back. The order follows the sequential focus order, which by default matches the order of elements in the document source.

Native interactive elements such as links, buttons, form fields and selects are focusable by default and come with expected key behavior. Custom widgets built from generic containers are not, so developers must add focusability with tabindex and handle keys in script. This is why native elements are the safer first choice.

WCAG requirements for keyboard access

The Web Content Accessibility Guidelines treat keyboard access as part of the principle of operability. Several success criteria apply directly, and together they define what an accessible keyboard experience must provide at conformance level AA, which most legal and procurement rules reference.

WCAG 2.2 also adds a AAA criterion on focus appearance, which describes a minimum size and contrast for the focus indicator. Even where AAA is not required, its guidance of a clearly contrasting outline is a sound design target.

Focus management in dynamic interfaces

Static pages mostly handle focus by themselves, but dynamic interfaces must manage focus deliberately. When content opens, closes or changes without a page load, the script must decide where focus goes, otherwise keyboard and screen reader users lose their place.

• Modal dialogs: move focus into the dialog on open, keep it trapped inside while open, and return it to the triggering control on close.
• Composite widgets: use a roving tabindex so that Tab enters the widget once and arrow keys move between items.
• Single-page navigation: after a route change, move focus to the new main heading or content region.
• Skip links: offer a first focusable link that jumps past repeated navigation to the main content.
• Removed elements: when a focused item is deleted, send focus to a logical neighbor, not to the top of the page.

ARIA roles and states describe custom widgets to assistive technology, but they add no keyboard behavior. A container marked with a button role still needs focusability and handlers for Enter and Space, which is another reason to prefer the native element.

Values of tabindex and when to use them

The tabindex attribute controls whether and how an element participates in sequential focus. Misused tabindex values are among the most common causes of a broken focus order, so each value has a narrow purpose.

Positive tabindex values override the natural order for the entire page and become unmaintainable as content changes. Fixing the source order of the markup is the correct way to change the focus sequence.

Testing keyboard navigation and common failures

The most reliable test is manual: unplug the mouse and complete every key task with the keyboard alone. Automated checkers can detect some missing attributes but cannot judge focus order or whether a custom widget responds to the right keys.

A visible focus style should contrast clearly with its surroundings; a contrast ratio of at least 3:1 against adjacent colors is a practical baseline. Styles applied through :focus-visible let designers show a strong indicator for keyboard users without affecting mouse clicks.

In plain words

Keyboard navigation means a person can use a whole website or app without a mouse. The Tab key moves from item to item. Enter or Space makes the selected item act. A highlighted outline shows which item is selected, much like a text cursor shows where typing will appear.

Many people depend on this every day. Some cannot hold a mouse steadily. Others cannot see the screen at all. If one button only works with a click, that button is out of reach for them.

A real-world example

A public transport company launches a new journey planner, and an accessibility audit is run before release. The tester completes the core task, planning a trip and buying a ticket, using only the keyboard. Within minutes two blockers appear: the date picker cannot be opened without a mouse, and the payment dialog lets focus escape to the page behind it.

The team replaces the custom date control with an accessible version that supports arrow keys, Page Up and Page Down for months and Escape to close. The dialog now moves focus to its heading on open, traps focus inside and returns it to the buy button on close. A 3-pixel focus outline replaces the removed default.

On retest, the full purchase takes about 25 keystrokes with no dead ends, and the service meets the keyboard criteria at level AA before launch.