Pick up your mouse and set it aside. Now try to use your website using only the keyboard. Press Tab to move forward, Shift+Tab to move back, Enter to activate links and buttons, and the arrow keys to scroll and navigate. Can you reach every link, every button, every form field, and every menu? Can you tell where you are on the page at all times? Can you complete your primary task, whether that is filling out a contact form, adding a product to a cart, or finding a phone number?

If the answer is no, your website has a keyboard accessibility problem. And you are not alone. Keyboard accessibility issues are among the most common barriers found on the web today, affecting a wide range of users who cannot use a mouse or simply prefer not to.

The good news is that keyboard accessibility is one of the most straightforward areas of web accessibility to understand and fix. In this guide, we will cover who relies on keyboard navigation, what the WCAG requirements are, and the specific steps you can take to ensure your site works for everyone, mouse or no mouse.

Who Navigates the Web Without a Mouse?

Keyboard navigation is not a niche concern. A wide range of users depend on it, and many more benefit from it.

People With Motor Disabilities

Users with conditions that affect fine motor control, such as cerebral palsy, muscular dystrophy, Parkinson’s disease, arthritis, or spinal cord injuries, may not be able to grip and move a mouse precisely. Many use a keyboard exclusively, sometimes with adaptive switches or specialized input devices that emulate keyboard input.

Screen Reader Users

People who are blind or have low vision typically use screen readers like JAWS, NVDA, or VoiceOver. Screen readers interact with web content through keyboard commands. When a screen reader user navigates a page, they are effectively keyboard users. If your site does not work with a keyboard, it will not work with a screen reader.

People With Repetitive Strain Injuries

Users with carpal tunnel syndrome, tendonitis, or other repetitive strain injuries may find mouse use painful. Keyboard navigation lets them browse without aggravating their condition.

Power Users

Many developers, writers, and other professionals prefer keyboard navigation because it is faster. Keyboard shortcuts are a hallmark of productivity tools for a reason: keeping your hands on the keyboard is simply more efficient.

Users on Certain Devices

Some touch devices and kiosks interact with web content through keyboard-like input. Ensuring keyboard compatibility makes your site work across a wider range of devices and contexts.

The bottom line: if your site only works with a mouse, you are excluding a significant portion of your audience.

How Keyboard Navigation Works on the Web

Browsers have built in keyboard navigation support. The most important keys and combinations are:

  • Tab: Moves focus to the next focusable element (links, buttons, form fields, etc.).
  • Shift+Tab: Moves focus to the previous focusable element.
  • Enter: Activates the focused link or button, or submits a form.
  • Space: Activates buttons and toggles checkboxes.
  • Arrow keys: Navigate within certain elements, such as radio button groups, select menus, tab interfaces, and sliders.
  • Escape: Often used to close modals, dropdowns, and menus.

When you press Tab, the browser moves something called “focus” from one interactive element to the next. Focus is the element that currently receives keyboard input. The visual indicator that shows which element has focus is called the “focus indicator” or “focus ring.”

For keyboard navigation to work properly, three things must be true:

  1. Every interactive element must be reachable using the keyboard.
  2. The order in which elements receive focus must be logical and predictable.
  3. The user must always be able to see where focus is on the page.

Let us look at each of these in detail, along with the WCAG requirements that govern them.

The WCAG Requirements for Keyboard Accessibility

The Web Content Accessibility Guidelines (WCAG) include several success criteria that specifically address keyboard access. These are some of the most fundamental requirements in the entire standard.

WCAG 2.1.1: Keyboard (Level A)

This is the foundational keyboard requirement. It states that all functionality of the content must be operable through a keyboard interface, without requiring specific timings for individual keystrokes.

In plain terms: if you can do it with a mouse, you must be able to do it with a keyboard. Clicking a button, opening a dropdown, expanding an accordion, submitting a form, playing a video, closing a modal. All of it must work without a mouse.

There is a narrow exception for content that requires freehand drawing or path-dependent input, but this is rare. For the vast majority of websites, everything must be keyboard operable.

WCAG 2.1.2: No Keyboard Trap (Level A)

This requirement states that if focus can be moved to a component using a keyboard interface, then focus can also be moved away from it using only a keyboard interface. If you need more than standard arrow keys, Tab, or Shift+Tab to leave, you must provide instructions for how to leave.

A “keyboard trap” happens when a user tabs into an element and cannot tab out of it. The most common culprit is a modal dialog that captures focus but does not provide a way to close it with the keyboard. The user is stuck and has to reach for the mouse or refresh the page.

WCAG 2.4.3: Focus Order (Level A)

Focus order must follow a logical and meaningful sequence. When a keyboard user tabs through your page, the elements should receive focus in an order that makes sense and preserves meaning and operability.

Normally, the browser handles this automatically based on the order of elements in the HTML. Problems arise when developers use CSS or JavaScript to visually reorder elements without updating the underlying HTML order. The visual order and the focus order should match.

WCAG 2.4.7: Focus Visible (Level A)

Any keyboard operable user interface must have a mode of operation where the keyboard focus indicator is visible. In other words, the user must always be able to see where they are on the page.

This is one of the most frequently violated WCAG criteria. Many designers remove the default browser focus outline for aesthetic reasons without providing an alternative. The result is an invisible focus state that makes keyboard navigation impossible.

WCAG 2.4.11: Focus Not Obscured (Level AA, introduced in WCAG 2.2)

This newer criterion requires that when a component receives keyboard focus, it is not entirely hidden by other content. For example, if a sticky header covers the element you just tabbed to, that fails this requirement. The focused element must remain at least partially visible.

WCAG 2.4.13: Focus Appearance (Level AAA, introduced in WCAG 2.2)

For the highest level of compliance, the focus indicator must meet specific size and contrast requirements. While this is Level AAA and not required for most organizations, it provides excellent guidance for designing strong focus indicators.

For a broader understanding of how WCAG levels work, see our guide on the levels of WCAG compliance.

Common Keyboard Accessibility Barriers

Now let us look at the specific problems that prevent keyboard users from navigating a site effectively.

1. Missing Focus Indicators

This is the single most common keyboard accessibility issue. Developers add CSS like outline: none; to remove the default focus ring, often because they find it ugly, but fail to replace it with a custom focus style. Without a visible focus indicator, a keyboard user has no idea which element they are currently on.

The fix is straightforward. Never remove the focus outline without providing an alternative. A good focus indicator should:

  • Have a contrast ratio of at least 3:1 against the adjacent background.
  • Be at least 2 pixels thick.
  • Be clearly distinguishable from the element’s normal state.
  • Be visible on every interactive element, including links, buttons, form fields, and custom widgets.

2. Non-Keyboard-Accessible Custom Widgets

Modern websites use custom JavaScript widgets for dropdowns, mega menus, accordions, carousels, tab panels, and modal dialogs. When these are built with div or span elements instead of semantic HTML, they are not focusable by default and do not respond to keyboard input.

For example, a “button” built as <div onclick="submitForm()">Submit</div> cannot receive keyboard focus and cannot be activated with Enter or Space. The user can tab right past it without knowing it exists.

The solution is to use semantic HTML elements (<button>, <a>, <input>, <select>) whenever possible. When custom widgets are necessary, you must add keyboard support using the tabindex attribute and JavaScript keyboard event handlers. This typically involves implementing the keyboard interaction patterns defined in the ARIA Authoring Practices Guide, which specifies which keys each type of widget should respond to.

For more on ARIA and how it supports keyboard interaction, see our guide on using ARIA for web accessibility.

3. Keyboard Traps in Modals and Embedded Content

A modal dialog that opens but cannot be closed with the keyboard is a classic trap. The user tabs into the modal, reaches the last focusable element inside it, and then focus either disappears or cycles back to the first element. There is no way out.

Other common traps include embedded media players, rich text editors, and third party widgets that capture keyboard input without releasing it. The Escape key should always close modals and dropdowns, and focus should return to the element that triggered the modal.

4. Illogical Focus Order

When the visual layout of a page does not match the HTML source order, keyboard users can experience confusing focus jumps. For example, if a sidebar is positioned on the left with CSS but appears after the main content in the HTML, a keyboard user tabbing through the page will jump from the header to the main content, then back up to the sidebar.

Using CSS properties like flex-direction: row-reverse, order, or absolute positioning can create this mismatch. The solution is to structure your HTML in a logical reading order and let CSS handle the visual layout without changing the tab order.

A “skip to main content” link is a keyboard accessibility essential. Without it, a keyboard user has to tab through every navigation link, every menu item, and every header element on every page before reaching the main content. On a site with a large navigation menu, this can mean pressing Tab dozens of times.

A skip link is typically the first focusable element on the page. It is visually hidden until it receives focus, at which point it becomes visible and lets the user jump directly to the main content area.

Sometimes interactive elements are present in the HTML but are not visible or usable. This can happen when:

  • An element has display: none or visibility: hidden but is still in the tab order due to a scripting error.
  • A link has no text content and no accessible name, making it invisible to both keyboard users and screen reader users.
  • A button is covered by another element, making it focusable but not clickable.

7. Drop-Down Menus That Require Hover

Many navigation menus expand on mouse hover and collapse when the mouse moves away. This pattern is inherently inaccessible to keyboard users because there is no hover state with a keyboard. If the submenu items are not reachable with Tab or arrow keys, keyboard users cannot access them.

The fix is to make menus expand on click (or on Enter/Space for keyboard users) and ensure all submenu items are reachable via keyboard.

How to Make Your Site Keyboard Accessible

Now for the practical steps. Here is what you need to do to ensure your site is fully keyboard navigable.

1. Use Semantic HTML

This is the most important principle and it solves the majority of keyboard accessibility issues with zero JavaScript. Semantic HTML elements have built in keyboard support:

  • <button> elements are focusable by default and respond to Enter and Space.
  • <a href> links are focusable and respond to Enter.
  • <input>, <select>, and <textarea> elements are focusable and respond to keyboard input.
  • <details> and <summary> elements create native accordions that work with the keyboard.

If you use these elements instead of <div onclick>, you get keyboard accessibility for free. The browser handles focus management, key handling, and focus indication automatically.

2. Never Remove the Focus Outline Without a Replacement

If you must customize the focus indicator, replace the default outline with something at least as visible. Here is an example of a strong custom focus style:

a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

The :focus-visible pseudo-class is preferred over :focus because it only shows the focus ring for keyboard users, not for mouse clicks. This gives you the best of both worlds: a clean look for mouse users and a clear focus indicator for keyboard users.

Place a skip link as the first element in your page body. Here is how:

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

<main id="main-content">
  <!-- Your main content here -->
</main>

Style it so it is visually hidden until it receives focus:

.skip-link {
  position: absolute;
  top: -100px;
  left: 0;
  background: #005fcc;
  color: white;
  padding: 8px 16px;
  z-index: 1000;
}

.skip-link:focus {
  top: 0;
}

This is one of the highest impact keyboard accessibility fixes you can make. It saves keyboard users from tabbing through the entire navigation on every page load.

4. Build Custom Widgets With Proper Keyboard Support

When you cannot use a native HTML element, you must add keyboard support manually. This involves three steps:

  1. Make the element focusable by adding tabindex="0" (for elements that should be in the natural tab order) or tabindex="-1" (for elements that should be focusable programmatically but not via Tab).

  2. Add keyboard event handlers that respond to the appropriate keys. For example, a custom button should respond to both Enter and Space:

element.addEventListener('keydown', function(event) {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    // Perform the button's action
  }
});
  1. Manage focus when content changes dynamically. When a modal opens, move focus into it. When it closes, return focus to the element that opened it. When new content loads via AJAX, move focus to it so the user knows it appeared.

5. Test Focus Order Against Visual Order

Tab through every page on your site and verify that the focus order matches the visual reading order, top to bottom and left to right. If focus jumps around unexpectedly, you likely have a mismatch between your HTML source order and your CSS layout. Fix the HTML order so it matches the visual layout.

6. Ensure All Interactive Elements Are Reachable

Tab through your entire page and make a list of every interactive element you encounter. Then compare that list to what you see on screen. Are there buttons, links, or form fields that you can see but cannot tab to? Those elements have a keyboard accessibility problem.

Common causes include:

  • Using tabindex="-1" incorrectly, which removes an element from the tab order.
  • Using tabindex values greater than 0, which disrupts the natural tab order and creates a maintenance nightmare.
  • Wrapping interactive elements in a container with tabindex="0" instead of making the interactive element itself focusable.

As a general rule, avoid tabindex values greater than 0. Let the browser manage the tab order based on your HTML structure.

7. Make Modals and Dialogs Keyboard Safe

Every modal dialog should follow these rules:

  • Focus must move to the modal (or its first focusable element) when it opens.
  • Focus must be trapped inside the modal while it is open. Tabbing past the last focusable element should cycle back to the first, and Shift+Tab past the first should cycle to the last.
  • The Escape key must close the modal.
  • When the modal closes, focus must return to the element that triggered it.

The native <dialog> element handles much of this automatically in modern browsers. For custom implementations, you will need JavaScript to manage focus trapping and restoration.

How to Test for Keyboard Accessibility

Keyboard accessibility testing is refreshingly low tech. You do not need any special tools, just a keyboard and some patience. Here is a testing checklist:

  1. Unplug your mouse (or put it aside) and try to use your site. This is the most effective test there is. If you cannot complete your primary tasks, you have found a problem.

  2. Tab through every page. Start at the top and press Tab repeatedly. Verify that:

    • Every interactive element receives focus.
    • No interactive elements are skipped.
    • The focus order is logical and matches the visual layout.
    • The focus indicator is always visible and clear.

  3. Test all interactive components. For each dropdown, accordion, modal, tab panel, carousel, and form:

    • Can you open and close it with the keyboard?
    • Can you navigate within it using arrow keys or Tab?
    • Can you escape from it?
    • Does focus return to a sensible place when it closes?

  4. Check for keyboard traps. Tab into every modal, media player, and embedded widget. Can you tab back out? If not, you have a trap.

  5. Verify the skip link. Press Tab as soon as the page loads. Is the first thing you land on a “skip to main content” link? Does it work when you press Enter?

  6. Test form submission. Can you fill out and submit every form using only the keyboard? Can you navigate between fields with Tab and Shift+Tab?

For a comprehensive testing approach that goes beyond keyboard accessibility, see our guide on how to test the accessibility of your website. You can also use accessibility testing tools to automate detection of some keyboard issues, though manual keyboard testing is always essential since many problems can only be found by actually trying to navigate without a mouse.

How Keyboard Accessibility Fits Into the Bigger Picture

Keyboard accessibility is not an isolated concern. It intersects with nearly every other area of web accessibility:

  • Screen reader users rely on keyboard navigation, so keyboard barriers are also screen reader barriers. Read more about ARIA and screen reader support.
  • Form accessibility depends on keyboard operability. If a form field cannot receive focus, it cannot be filled out. See our guide on accessible forms.
  • Mobile accessibility shares many principles with keyboard accessibility, since touch screen readers and switch devices use similar navigation patterns. Learn more about mobile web accessibility.
  • Cognitive accessibility benefits from predictable focus order and clear focus indicators, which reduce cognitive load. See our guide on cognitive accessibility.

Keyboard accessibility is also a legal requirement. WCAG 2.1.1 (Keyboard) and 2.4.7 (Focus Visible) are both Level A criteria, the minimum standard for accessibility. Failing them means your site does not meet baseline accessibility requirements. Learn more about ADA compliance requirements and how they apply to your organization.

Quick Wins to Get Started

You do not need to overhaul your entire site to improve keyboard accessibility. Start with these high impact fixes:

  1. Restore focus indicators. Search your CSS for outline: none and outline: 0. For each one, either remove it or add a replacement focus style using :focus-visible.

  2. Add a skip link. It takes a few lines of HTML and CSS and immediately improves the experience for every keyboard user.

  3. Replace div buttons with real buttons. Search your codebase for <div onclick and <span onclick and replace them with <button> elements. This is the single biggest source of keyboard inaccessibility.

  4. Fix modal traps. Make sure every modal can be closed with the Escape key and that focus returns to the triggering element.

  5. Tab through your key user flows. Spend fifteen minutes tabbing through your homepage, your most important form, and your checkout or contact process. Note every barrier you encounter and prioritize fixing the ones that block task completion.

Then run a full accessibility scan to catch the technical issues you may have missed. Accessible Metrics checks your site against WCAG 2.1 AA standards, including all keyboard operability and focus related criteria.

Ready to see how your site performs? Run a free accessibility scan with Accessible Metrics and get a detailed report against WCAG 2.1 AA standards, including keyboard navigation, focus order, and focus visibility issues that affect users who navigate without a mouse.