Keyboard Navigation: Making Your Website Fully Accessible

Why Keyboard Accessibility Matters

Keyboard accessibility is one of the foundational requirements of web accessibility. Many people cannot use a mouse or pointing device — including people with motor disabilities, vision impairments, and some cognitive disabilities. These users rely on keyboards, switch devices, or other assistive technologies that emulate keyboard input to navigate and interact with websites.

Under WCAG 2.1, keyboard accessibility is covered by several success criteria, most notably 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap) at Level A, and 2.4.7 (Focus Visible) at Level AA. The European Accessibility Act requires WCAG 2.1 AA compliance, making keyboard accessibility a legal requirement for most EU businesses.

WCAG Keyboard Requirements

2.1.1 Keyboard (Level A)

All functionality of the content must be operable through a keyboard interface without requiring specific timings for individual keystrokes. This means every link, button, form field, dropdown, dialog, tab panel, slider, and custom widget must work with keyboard alone.

2.1.2 No Keyboard Trap (Level A)

If keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using only a keyboard. If it requires more than unmodified arrow or tab keys, the user must be informed of the method for moving focus away.

2.1.4 Character Key Shortcuts (Level A, WCAG 2.1)

If a keyboard shortcut uses only letter, punctuation, number, or symbol characters, the user must be able to turn it off, remap it, or it is only active when the relevant component has focus.

2.4.3 Focus Order (Level A)

If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

2.4.7 Focus Visible (Level AA)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. Users must be able to see which element currently has focus.

Essential Keyboard Interactions

Here are the keyboard interactions users expect:

• Tab: Move focus to the next interactive element
• Shift + Tab: Move focus to the previous interactive element
• Enter: Activate links and buttons
• Space: Activate buttons, check/uncheck checkboxes, toggle controls
• Arrow keys: Navigate within radio groups, tabs, menus, and other composite widgets
• Escape: Close dialogs, menus, and popups
• Home/End: Move to first/last item in a list or menu

Common Keyboard Accessibility Issues

1. Click-Only Event Handlers

When JavaScript functionality is attached only to click events on non-interactive elements (like divs and spans), keyboard users cannot activate them. Always use native interactive elements (button, a, input) or add keyboard event handlers alongside click handlers.

2. Invisible Focus Indicators

Many websites use outline: none in their CSS to remove the default focus ring for aesthetic reasons. This makes it impossible for keyboard users to know which element has focus. Instead of removing focus indicators, style them to match your design.

/* Bad */
*:focus { outline: none; }

/* Good */
*:focus-visible {
  outline: 2px solid #0066CC;
  outline-offset: 2px;
}

3. Keyboard Traps

Modal dialogs, embedded media players, and third-party widgets sometimes trap keyboard focus, preventing users from navigating away. Always ensure that pressing Escape closes dialogs and returns focus to the triggering element.

4. Missing Skip Navigation

Without a skip navigation link, keyboard users must tab through every navigation link on every page before reaching the main content. A skip link should be the first focusable element on the page.

5. Custom Dropdown Menus

Custom dropdown menus built with divs and JavaScript often lack keyboard support. They need to support arrow key navigation, Escape to close, and proper focus management.

6. Inaccessible Carousels and Sliders

Image carousels and content sliders frequently lack keyboard controls for advancing slides, pausing auto-play, and navigating to specific slides.

Implementing Skip Navigation

A skip navigation link allows keyboard users to jump directly to the main content, bypassing the header and navigation:

<body>
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <header>...navigation...</header>
  <main id="main-content">
    ...page content...
  </main>
</body>

/* CSS: visible only on focus */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  z-index: 100;
}
.skip-link:focus {
  top: 0;
}

Focus Management for Dynamic Content

When content changes dynamically, focus must be managed carefully:

Modal Dialogs

1. When the dialog opens, move focus to the first interactive element in the dialog (or the dialog itself)
2. Trap focus within the dialog — Tab and Shift+Tab should cycle through dialog elements only
3. Escape should close the dialog
4. When the dialog closes, return focus to the element that triggered it

Dynamic Page Updates

When a user action causes content to appear or change (e.g., expanding an accordion, loading search results), consider whether focus needs to move to the new content. For non-critical updates, use aria-live regions. For critical navigation changes, move focus to the new content.

Testing Keyboard Accessibility

Testing keyboard accessibility is straightforward:

1. Put your mouse away: Navigate your entire website using only the keyboard
2. Tab through every page: Can you reach every interactive element? Is the focus visible? Is the order logical?
3. Activate everything: Can you click every button, follow every link, submit every form, open every dropdown using Enter and Space?
4. Test custom components: Do carousels, accordions, tabs, and dialogs work with keyboard?
5. Check for traps: Can you always Tab away from every component? Can you Escape from dialogs?

Automate What You Can

While keyboard testing is inherently manual, automated tools can catch some keyboard-related issues. EAAPass can detect missing skip links, elements with tabindex issues, missing focus styles, and interactive elements that are not keyboard accessible. Use automated testing as your first step, then follow up with manual keyboard testing.

Start with a free EAAPass audit to identify keyboard accessibility issues across your entire site, then use this guide to complete your manual testing.