Who Uses Keyboard Navigation?
Keyboard navigation is not a niche concern. A wide range of people depend on it as their primary way of interacting with websites:
- People with motor disabilities: Conditions like cerebral palsy, muscular dystrophy, repetitive strain injury, or arthritis can make using a mouse painful or impossible. Many of these users rely on keyboards, switch devices, or sip-and-puff systems that emulate keyboard input.
- Screen reader users: People who are blind navigate almost entirely by keyboard. Screen readers use keyboard commands to move through page elements, open menus, and activate controls.
- People with temporary injuries: A broken wrist, a sprained hand, or post-surgical recovery can temporarily make someone a keyboard-only user.
- Power users: Many developers, data entry professionals, and experienced computer users prefer keyboard navigation because it is faster than reaching for a mouse.
WCAG 2.2 Level A requires that all functionality be available from a keyboard (Success Criterion 2.1.1). This is one of the foundational requirements of web accessibility and is critical for ADA compliance.
How Keyboard Navigation Works
When someone navigates a website by keyboard, they use a small set of keys to move through interactive elements and trigger actions. Here are the most important ones:
| Key | What It Does |
|---|---|
Tab | Moves focus to the next interactive element (link, button, input, select) |
Shift + Tab | Moves focus to the previous interactive element |
Enter | Activates a link or button |
Space | Activates a button, toggles a checkbox, or opens a dropdown |
Arrow keys | Navigate within components like radio groups, tab panels, or menus |
Escape | Closes a modal, dropdown, or overlay |
The browser handles most of this behavior automatically -- but only when the
correct HTML elements are used. Native
<button>,
<a>,
<input>, and
<select>
elements are keyboard accessible by default. Custom elements built from
<div> and
<span> tags are not.
Focus Indicators: The Visual Lifeline
When a keyboard user tabs through a page, they need to see which element currently has focus. This visual indicator -- usually an outline or highlight around the focused element -- is called a focus indicator. It is the keyboard equivalent of a mouse cursor.
Browsers provide a default focus indicator, typically a thin blue or black
outline. Unfortunately, many websites remove this outline with CSS (using
outline: none) because designers
find it visually distracting for mouse users. This is one of the most harmful
accessibility mistakes a site can make. Without a focus indicator, a keyboard
user is navigating blind.
The right approach is to use the
:focus-visible CSS pseudo-class.
This shows focus indicators only when the user is navigating by keyboard, not
when they click with a mouse. It gives you the best of both worlds: clean
visuals for mouse users and clear focus indicators for keyboard users.
WCAG 2.2 added a new Level AA criterion called Focus Not Obscured (2.4.11), which requires that when an element receives focus, it is not entirely hidden by other content like sticky headers, cookie banners, or chat widgets. If your focus indicator is hidden behind a sticky navigation bar, it does not count as visible.
Common Keyboard Accessibility Failures
These are the issues keyboard users encounter most often on business websites:
Keyboard Traps
A keyboard trap occurs when a user can tab into a component but cannot tab out of it. This commonly happens with embedded maps, video players, or poorly coded modal dialogs. The user is stuck and may need to close the browser tab entirely. WCAG 2.1.2 (Level A) explicitly prohibits keyboard traps.
Removed Focus Outlines
Removing focus indicators with outline: none
without providing a replacement leaves keyboard users unable to see where
they are on the page. Always use :focus-visible
or provide custom focus styles.
Mouse-Only Interactions
Dropdown menus that open only on hover, drag-and-drop functionality without keyboard alternatives, or custom sliders that only respond to mouse events all exclude keyboard users. Every interactive element must have a keyboard equivalent.
Illogical Tab Order
Focus should move through the page in a logical order that matches the
visual layout -- typically left to right, top to bottom. Using positive
tabindex values or rearranging
elements with CSS without adjusting the DOM order creates a confusing
navigation sequence.
No Skip Navigation
Without a "skip to main content" link at the top of the page, keyboard users must tab through every navigation link on every page load before reaching the actual content. On a site with 20 nav links, that is 20 Tab presses just to start reading.
How to Test Keyboard Accessibility
Keyboard testing is the easiest accessibility test you can run. You do not need any special software -- just your keyboard.
Step 1: Put Down the Mouse
Disconnect your mouse or move it out of reach. You need to rely entirely on the keyboard to get an honest picture of the experience.
Step 2: Tab Through Every Page
Start at the top of the page and press Tab repeatedly. Watch for: Can you see where focus is at all times? Does the focus order make sense? Can you reach every interactive element?
Step 3: Interact With Everything
Try to activate every button, link, dropdown menu, and form field using only the keyboard. Open and close modal dialogs. Submit forms. Use any custom widgets like carousels, accordions, or tabs.
Step 4: Check for Traps
At each interactive component, verify you can tab out of it. Pay special attention to embedded content (maps, videos, iframes), modal dialogs, and form elements.
Step 5: Complete a Task
Try the most common task your customers perform -- whether that is filling out a contact form, browsing your services, or finding your phone number. If you cannot complete it by keyboard alone, neither can your keyboard- dependent customers.
Best Practices for Keyboard-Accessible Design
- Use native HTML elements: Buttons, links, inputs, and selects are keyboard accessible by default. Use them instead of styling divs and spans to look interactive.
- Add a skip navigation link: Place a "Skip to main content" link as the first focusable element on the page. It should be visually hidden until focused.
- Preserve focus indicators: Never remove focus outlines without providing a visible alternative. Use
:focus-visiblefor keyboard-only styles. - Manage focus in modals: When a modal opens, move focus into it. When it closes, return focus to the element that triggered it. Trap focus inside the modal so Tab does not wander behind it.
- Support Escape to close: Any overlay, dropdown, or modal should close when the user presses Escape.
- Avoid positive tabindex: Never use
tabindexvalues greater than 0. They override the natural DOM order and create unpredictable navigation. - Make hover interactions keyboard accessible: If a dropdown opens on hover, it must also open on focus or through a keyboard-activated toggle.
- Provide keyboard alternatives for drag-and-drop: WCAG 2.2 requires that any drag functionality has a simple pointer or keyboard alternative.