Keyboard Navigation

Understanding Keyboard Navigation

Keyboard navigation allows visitors to move through and operate interactive webpage content without using a mouse or touchscreen.

Many people rely on a keyboard or keyboard-like device to browse the web. Accessible pages use native HTML controls, logical source order, visible focus indicators, and predictable interaction so links, buttons, form fields, menus, and other controls can be reached and used from the keyboard.

Why Keyboard Access Matters

Not everyone uses a mouse to interact with webpages. Some visitors use a keyboard because of a motor disability, visual impairment, temporary injury, personal preference, or because they use assistive technology that provides keyboard-like controls.

If an interactive element can only be reached, activated, opened, or dismissed with a mouse, some visitors may be unable to use that part of the page.

Keyboard accessibility is therefore an important part of making links, forms, navigation, dialogs, menus, and other interactive content usable by a wider range of people.

Use Native Keyboard Support

Native HTML elements already include much of the keyboard behavior users expect. Links, buttons, form controls, and other interactive elements can normally receive focus and respond to appropriate keyboard commands without additional scripting.

<a href="/contact.html">Contact Us</a>

<button type="button">Show Details</button>

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

Using the correct native element is usually more reliable than recreating the same behavior with a generic <div> or <span>.

Maintain a Logical Tab Order

Pressing the Tab key normally moves focus through interactive elements in the order they appear in the document. A logical HTML source order therefore helps create a predictable keyboard navigation sequence.

<a href="/products.html">Products</a>
<a href="/services.html">Services</a>
<a href="/contact.html">Contact</a>

In this example, focus moves from Products to Services to Contact because that is the order of the links in the HTML.

Visual layouts created with CSS should not produce a keyboard order that feels unrelated to what visitors see on the screen. Whenever practical, keep the visual presentation and source order consistent.

Use Tabindex Carefully

The tabindex attribute can affect whether an element receives keyboard focus and where it appears in the tab sequence, but it should be used carefully.

Avoid positive values such as tabindex="1", tabindex="2", and higher values for ordinary page navigation. Fixing the HTML source order is usually a better solution.

Also avoid adding tabindex="0" to non-interactive content unless there is a genuine reason for that content to receive keyboard focus.

Keep Focus Visible

Keyboard users need a clear visual indication of which interactive element currently has focus. Browsers provide default focus styles, and these should not be removed unless an equally visible replacement is provided.

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

A rule such as outline: none; can make keyboard navigation difficult when it removes the only visible indication of focus.

The next tutorial, Keyboard Focus, covers focus behavior and management in greater detail.

Provide Skip Links

Pages with repeated navigation can require keyboard users to tab through many links before reaching the main content. A skip link provides a quick way to bypass repeated content.

<a href="#main-content" class="skip-link">Skip to main content</a>

<nav>
  ...
</nav>

<main id="main-content">
  ...
</main>

A skip link is often positioned near the beginning of the HTML and may remain visually hidden until it receives keyboard focus.

The destination should be clearly identified so activating the link moves the visitor directly to the intended content.

Avoid Keyboard Traps

A keyboard trap occurs when focus enters part of a webpage but the user cannot move away from it using the keyboard. Visitors should be able to enter and leave interactive components using expected keyboard controls.

Dialogs, embedded content, custom menus, widgets, and scripted interfaces deserve particular attention because their behavior may change how focus moves through the page.

When a component intentionally keeps focus within itself for a period of time, such as an open modal dialog, it must still provide an accessible way to close the component and return to the surrounding page.

Custom Interactive Controls

Custom controls created with JavaScript require more work than native HTML controls because keyboard behavior, focusability, semantics, and interaction patterns may need to be added manually.

This generic element may look clickable after CSS is applied, but it is not automatically a keyboard-accessible button:

<div class="button">Show Details</div>

When the element performs a button action, use a real button instead:

<button type="button">Show Details</button>

If a genuinely custom widget is necessary, follow the established keyboard interaction pattern for that type of component rather than inventing an unexpected set of keyboard commands.

Testing Keyboard Navigation

One of the simplest accessibility tests is to put the mouse aside and try using the page with only the keyboard.

Use Tab to move forward through interactive controls and Shift+Tab to move backward. Activate links and buttons with their expected keyboard commands and make sure menus, forms, dialogs, and other interactive components remain usable.

While testing, check that every interactive control can be reached, the focus order makes sense, focus remains visible, and no component traps the keyboard unexpectedly.

Keyboard Navigation Example

The following example uses native links, form controls, and a button in a logical source order. It also includes a skip link that moves directly to the main content.

<a href="#main-content">Skip to main content</a>

<nav aria-label="Main navigation">
  <a href="/products.html">Products</a>
  <a href="/services.html">Services</a>
  <a href="/contact.html">Contact</a>
</nav>

<main id="main-content">
  <h1>Garden Center Newsletter</h1>

  <label for="email">Email Address</label>
  <input type="email" id="email" name="email">

  <button type="button">Subscribe</button>
</main>

Open the example and navigate without using the mouse. Use Tab and Shift+Tab to follow the focus order, then activate the skip link to move directly to the main content.

Best Practices

• Use native HTML links, buttons, and form controls whenever possible.
• Make every interactive feature usable with the keyboard.
• Keep interactive elements in a logical HTML source order.
• Avoid positive tabindex values for manually rearranging keyboard navigation.
• Do not add unnecessary elements to the tab sequence.
• Keep keyboard focus clearly visible.
• Provide a skip link when repeated navigation makes reaching the main content unnecessarily time-consuming.
• Make sure visitors can enter and leave interactive components without becoming trapped.
• Use established keyboard patterns when creating custom interactive widgets.
• Test important pages using only the keyboard.

Summary

Keyboard-accessible webpages allow visitors to reach and operate interactive content without depending on a mouse or touchscreen. Native HTML elements provide much of this behavior automatically when they are used correctly.

A logical source order, careful use of tabindex, visible focus indicators, skip links, and freedom from keyboard traps create a predictable navigation experience. Testing the page with only a keyboard is an effective way to discover many common accessibility problems.