Who relies on the keyboard
Many people never use a mouse on a website. Some have motor limitations that make precise pointing difficult. Some use screen readers, which are driven largely by keyboard commands. Others use switch devices, voice control or other assistive tools that behave like keyboard input. Plenty of people simply prefer the keyboard for speed. If a page cannot be operated this way, it excludes all of them.
Keyboard support is also one of the easiest accessibility areas to test yourself. It needs no software, only the Tab key and some patience.
The basic keys
Most keyboard use of a web page relies on a handful of keys:
- Tab moves forward to the next interactive element, and Shift+Tab moves back.
- Enter activates links and buttons.
- Space activates buttons, toggles checkboxes and scrolls the page.
- Arrow keys move within groups such as radio buttons, menus, tabs and sliders.
- Escape typically closes menus, dialogs and pop-ups.
Browser behaviors differ slightly, so test in the browsers your visitors use most. Interactive elements are generally links, buttons, form fields and anything else with an action. Plain text and images are usually skipped.
Focus order
When you press Tab, the element that becomes active has “focus.” The sequence in which elements receive focus is the focus order. It should usually follow the visual and reading order: top to bottom, left to right in left-to-right languages, with each region making sense as a group.
Problems typically arise when the layout on screen differs from the order of elements in the code. A design that visually moves the sidebar before the content, or a designer who positions things with styling instead of structure, can make focus jump unpredictably. Clear page structure is also good for other purposes, as discussed under site structure and heading structure.
Avoid forcing a custom order with positive tabindex values. They are fragile and tend to produce confusing sequences as pages grow. In most cases, putting elements in a sensible order in the code and letting the browser do its job works best.
Visible focus
You must be able to see where you are. A visible outline, highlight or underline should appear on whichever element has focus. A common mistake is to remove the default outline in the style sheet because it looks untidy, without providing a replacement. The result is a page where keyboard users have no idea which link or button is active.
Make the indicator clear against all backgrounds, including dark footers and images, and ensure it is distinguishable from the unfocused state. The contrast principles in color contrast apply to focus indicators too. A thick outline with an offset or a contrasting border generally works better than a subtle color shift.
Step-by-step test
- Load the page and press Tab once. The first stop should be a sensible element, often a skip link.
- Keep tabbing through the whole page. Note any element you cannot reach, any that is skipped, and any place where the focus indicator vanishes.
- Open every menu, accordion, tab panel and dialog using only the keyboard. Can you open it, move within it, and close it?
- Activate links and buttons with Enter or Space as appropriate.
- Fill out and submit a form, confirming that error messages can be reached.
- Try Shift+Tab to move backward and make sure the sequence mirrors the forward order.
- Watch for anything that appears on hover only. If a menu or tooltip shows only when the mouse hovers, keyboard users may never see it.
Write down each failure along with the page and element involved. This fits naturally with other accessibility checks.
Skip links
Most sites have a header and navigation menu before the main content. Keyboard users would have to tab through every item on every page to reach the content without a shortcut. A skip link, typically the first focusable element and often labeled something like “Skip to main content,” lets them jump past the repeated area. It may be hidden until focused, but it should become visible when it receives focus. If your navigation is long, this one addition makes a noticeable difference. Clear breadcrumb navigation and a tidy menu help everyone, as covered in the article on breadcrumb navigation.
Keyboard traps and dialogs
A keyboard trap occurs when focus enters an element and cannot leave. Embedded widgets, video players and poorly built dialogs are common culprits. If you can tab in but not out, that is a serious failure.
Dialogs, also called modal windows, need specific handling:
- When one opens, focus should move into it.
- While it is open, focus should stay inside it rather than wandering behind it.
- Escape or a clear close button should dismiss it.
- When it closes, focus should return to where the user was.
This is especially relevant to overlays and banners, which are discussed in intrusive pop-ups, since a pop-up that cannot be dismissed with a keyboard blocks the page entirely.
Custom controls
Standard HTML buttons, links and form fields work with the keyboard automatically. Problems tend to come from custom controls built from generic elements, such as a clickable box that is not a real button. These need additional code to be focusable and operable, and it is easy to get wrong. When a fix is available, replacing a custom element with the correct native one is often the simplest and most robust option.
What a good result looks like
You should be able to reach everything useful, see where you are at every step, operate every control, and leave every region. The experience does not need to be elegant, but it should be predictable. If your site uses a framework or a page builder, keep in mind that updates can change behavior, so recheck after major changes. Add a keyboard pass to your routine, such as the monthly routine suggested elsewhere, and combine it with a phone test and a real device check. No outcome in search is promised by this work, but the page becomes usable by more people.