Keyboard accessibility: a five-minute test you can do yourself

Many people do not use a mouse. Some have limited hand movement or tremors and use a keyboard, a switch device or voice control. People who are blind use a keyboard with a screen reader. Others simply prefer the keyboard. If a website cannot be operated from the keyboard alone, all of these people can be shut out of it, sometimes from a single essential step such as a booking button.

It is also an area where an owner can find real problems in a few minutes, with no special software.

The WCAG 2.1 criteria involved

In practice these work together. A person needs to reach every control (2.1.1), see where they are (2.4.7), move in a sensible order (2.4.3), avoid getting stuck (2.1.2), and not have to press Tab through the same twenty menu links on every page (2.4.1). The focus indicator must also be distinguishable from its surroundings; 1.4.11 Non-text Contrast asks for 3:1 for the visual information needed to identify a control's state.

A five-minute keyboard test

Open your home page and one page that matters to your customers, such as your contact or booking page. Click once in the browser address bar, then put the mouse aside. Use these keys:

• Tab moves forward to the next link, button or form field.
• Shift+Tab moves backward.
• Enter follows a link or activates a button.
• Space activates a button, ticks a check box, or scrolls the page.
• Esc should close a pop-up, menu or dialog.
• Arrow keys move within some controls, such as radio buttons, drop-down lists, sliders and tabs.

As you go, ask these questions:

1. Can I see where I am? After each Tab press, something on the screen should be clearly outlined or highlighted. If focus seems to disappear, that is a likely 2.4.7 failure.
2. Is there a "Skip to main content" link? It often appears only on the first Tab press. Activating it should move you past the navigation.
3. Does the order make sense? Focus should follow the reading order of the page, generally top to bottom and left to right. Jumping from the header to the footer and back is a sign of a focus order problem.
4. Can I open the menu? Try every drop-down in the main navigation. Can you reach the sub-pages without hovering a mouse?
5. Can I complete the main task? Fill in and submit your contact form, or start a booking, using only the keyboard.
6. Can I get out? If a pop-up opens, can you close it with Esc or a reachable close button, and does focus return to a sensible place?

Common failures

Navigation menus

Drop-down menus that open only on mouse hover are a frequent problem. The top-level link may be reachable, but the sub-pages never appear for a keyboard user. Mobile "hamburger" menus are sometimes built from a plain image or generic container that cannot receive focus at all. A menu toggle should be a real button that can be reached with Tab and opened with Enter or Space.

Sliders and carousels

Carousels often have previous and next arrows that are not focusable, or off-screen slides whose links still receive focus. A carousel that moves on its own also needs a way to pause it, which is covered in our article on video, audio and motion.

Pop-ups and dialogs

Newsletter sign-up boxes and cookie notices can cause two opposite problems. In one, focus stays behind the pop-up, so a keyboard user tabs through hidden page content while the pop-up blocks the screen. In the other, focus enters the pop-up and cannot leave because the close button is not reachable, which is a keyboard trap. A well-built dialog moves focus into itself when it opens, keeps focus inside while it is open, closes with Esc, and returns focus to where the user was.

Booking widgets and date pickers

Calendar pickers, time-slot grids and seat selectors are often built from elements that respond only to mouse clicks. A customer may be able to tab to the widget but not choose a date. Because these tools are often supplied by a vendor, see our article on third-party tools for how to assess them.

Custom buttons and removed outlines

Two code-level issues cause many of the problems above. The first is a "button" built from a generic element with a click handler, which the keyboard cannot reach. The second is a style rule that removes the browser's default focus outline for appearance, without providing a replacement. For example:

/* Removes the focus indicator for everyone */
a:focus, button:focus { outline: none; }

/* A replacement that keeps the design clean */
a:focus-visible, button:focus-visible {
  outline: 3px solid #1F4E79;
  outline-offset: 2px;
}

The second rule shows a clear outline to keyboard users while most browsers do not show it on mouse clicks, so the visual design for mouse users is unchanged.

Beyond the quick test

The five-minute test finds the most obvious barriers, not all of them. Our method combines automated scans with manual keyboard testing and screen reader testing in NVDA and VoiceOver. Our checklist lists other checks you can try yourself.

Talk to us

If your test turned up a menu you could not open or a form you could not submit, we can identify the cause and fix it without changing how your site looks. Read about our services or contact us to discuss your site.

Last reviewed October 2026.