Level Access

Author: Level Access

Keyboard navigation allows users to operate websites using only keystrokes (like Tab, Enter, and arrow keys) without requiring a mouse or pointer.

Some people with disabilities access digital experiences using the keyboard only, instead of a mouse, trackpad, or other pointing devices. In keyboard navigation, users rely on the Tab key, Enter key, arrow keys, and other keystrokes to efficiently move through a web page and engage with interactive elements.

Ensuring that websites are operable for keyboard-only users is a cornerstone of web accessibility. If a website contains keyboard traps (where keyboard users cannot exit a website element) or other barriers, people with a wide range of disabilities—including certain types of physical, motor, and visual disabilities—may not be able to navigate content. Many screen reader users rely on the keyboard, and some people with low vision prefer keyboard navigation because locating and tracking the mouse pointer can be time-consuming.

Keyboard accessibility also delivers a better experience for users without disabilities who prefer keyboard shortcuts for faster interaction. And it’s critical for compliance with accessibility laws, such as the Americans with Disabilities Act (ADA), Section 508, and the European Accessibility Act (EAA).

So, how can you provide an equitable experience for keyboard-only users? In this piece, we’ll take a deep dive into keyboard accessibility: why it matters, and what it means in practice. We’ll also provide quick tips for ensuring your website supports keyboard navigation.

Key insights

  • Many people with disabilities interact with websites using the keyboard, instead of a mouse or pointer. This includes users of assistive technology that operates through a keyboard interface.
  • Supporting keyboard navigation is critical for legal compliance as well as providing a functional user experience.
  • Native HTML elements are accessible to keyboard users by default.
  • Visible focus indicators and logical focus order are essential to keyboard navigation.
  • While formal keyboard accessibility testing should be performed by an expert, you can spot-check by unplugging your mouse and trying to navigate with the keyboard only.

Why keyboard accessibility matters

For many people—including those with certain types of physical or motor disabilities—keyboard navigation is the most reliable way to interact with websites. Other users find that using keyboard shortcuts is more efficient than using a pointing device. Making sure users can access your website using keyboard commands, not just with a mouse or pointer, is essential to providing a functional experience for everyone.

Many screen reader users rely on keyboard-accessible websites. These assistive technologies interpret and announce page elements based on focus and semantic structure, and users often move through content with keystrokes. If a website does not maintain keyboard focus or support logical focus order, screen reader navigation breaks down.

Other assistive technologies also operate with a keyboard interface, so keyboard support ensures that people can interact with a website, regardless of how they use assistive technology.

Websites that are not accessible to keyboard users may leave organizations vulnerable to digital accessibility lawsuits under the ADA and related laws.

Keyboard accessibility standards

Keyboard accessibility is essential for conformance with the Web Content Accessibility Guidelines (WCAG), the benchmark for compliance with the ADA, Section 508, EAA, EN 301 549 and other global accessibility laws and standards.

WCAG contains several conformance levels: Level A (the most basic), Level AA (the level required by most regulations), and Level AAA (the highest possible level). To conform with WCAG Level A, websites must provide keyboard access with no traps. Logical focus order and visible focus indicators are needed for Level AA conformance.

WCAG includes different success criteria related to access for keyboard users. These include:

  • 2.1.1 Keyboard
  • 2.1.2 No Keyboard Trap
  • 2.4.3 Focus Order
  • 2.4.7 Focus Visible
  • 2.4.11 Focus Not Obscured (introduced in the latest version, WCAG 2.2)

Meeting these requirements helps organizations reduce legal risk, and more importantly, it ensures keyboard users can complete tasks independently and confidently.

Keyboard navigation 101: The basics

Before you can make your website keyboard-accessible, you’ll need to understand how keyboard navigation works in practice.

What are the navigation keys on a keyboard?

Keyboard navigation relies on a collection of keys that perform specific actions that mirror mouse use. These simple keystrokes form the foundation of accessible navigation. Below is a table listing different keys and the actions that correspond to them.

Quick reference table 

Action Keys Works On
Move forward Tab All focusable elements
Move backward Shift + Tab All focusable elements
Activate Enter Links, buttons
Activate/Toggle Spacebar Buttons, checkboxes
Navigate options Arrow keys Radio buttons, menus, tab panel
Close/Cancel Escape Modal dialogs, menus

 

How does keyboard focus work?

Keyboard focus indicates which element is currently active and will respond to keyboard input. When users press Tab, focus moves to the next element that can receive keyboard focus, and a visible keyboard focus indicator appears around the focused element.

Browsers provide default focus styles, but developers may customize them to align with design systems. Regardless of styling, the focus indicator must remain visible so users can track their position on the page. The indicator should also have sufficient contrast to assist people with low vision. Without a visible indicator, users navigating with only a keyboard may lose context and be unable to continue.

Focus typically moves in a logical order, following the structure of the document from top to bottom. Interactive components such as links with an href attribute, buttons, or form controls automatically receive focus. Improper use of the tabindex attribute can disrupt focus order and cause accessibility issues.

How to use the keyboard for navigation 

Want to try keyboard navigation for yourself? Begin by pressing Tab to move into the first interactive element on a page. From there, use Tab to move focus sequentially through links, buttons, form controls, and menus.

Activate elements with Enter or Space, navigate grouped controls with arrow keys, and close dialogs with Esc. If the page you’re on is keyboard-accessible, you should be able to complete all interactions using only keystrokes, without needing a mouse or other pointing device.

Step-by-step guide 

  1. Disconnect your mouse and instead use your keyboard.
  2. Press the Tab key to start navigating.
  3. Identify the focus indicator. Instead of a mouse pointer, the indicator might be highlighted or enclosed text.
  4. Use Tab to move forward, Shift + Tab to move back.
  5. Press Enter or Spacebar to activate the focused element.
  6. Use arrow keys inside menus and radio buttons.
  7. Press Escape to close popups and modal dialogs.

Keyboard navigation on mobile devices 

Keyboard navigation isn’t limited to desktops. Many users connect external Bluetooth keyboards to mobile devices running iOS or Android. The same navigation rules apply: Tab moves focus, Enter activates, and Escape closes dialogs. Developers must ensure that touch-only features also respond to keyboard input.

Keyboard interface support is especially important on mobile because many assistive technologies—such as screen readers and switch control tools—rely on the same underlying focus model. On iOS and Android, features like VoiceOver and TalkBack map keyboard commands to accessibility focus movement, allowing users to navigate, activate controls, and interact with dynamic content without using touch.

When applications correctly support keyboard focus order, visible focus indicators, and standard activation keys, they create a consistent interaction model that works seamlessly across touch, keyboard, and assistive technology inputs. Testing accessibility on mobile devices is just as important as desktop testing, since mobile usage continues to grow.

Keyboard navigation and assistive technologies 

Keyboard navigation can be especially vital for users of assistive technologies, such as screen readers. Importantly, keyboard navigation by screen reader users differs from keyboard use by people without visual disabilities.

While users without visual disabilities rely on the focus indicator, screen readers announce the focused element and its role. Users can jump by headings, links, or landmarks, not just Tab. It’s important to remember not to put non-interactive elements in the focus order as screen readers have other ways of allowing users to reach that type of content.

Proper HTML structure ensures these assistive technologies interpret elements correctly. For example, a <button> is announced as “Button,” while a <div onclick> may be read as “Clickable,” which is less informative. ARIA attributes can provide additional context, but they should supplement—not replace—semantic HTML. If you create custom controls with ARIA, you might need to add in your own keyboard support.

Assistive technologies and keyboard shortcuts

Importantly, some assistive technologies may use keyboard shortcuts in addition to those already provided by browsers or operating systems. Screen readers like NVDA and JAWS use modifier keys such as Ctrl or Alt combined with letters to announce or navigate elements. For example, in NVDA, pressing H moves the user to the next heading on the page.

Developers should avoid creating custom shortcuts that conflict with these assistive commands. Voice control software might send keyboard commands, making consistency important. Documenting shortcuts ensures users can discover and use them effectively.

Making your website keyboard-accessible

The foundation of keyboard accessibility lies in native HTML elements. Buttons, links with href, and form inputs are inherently keyboard accessible. While developers should avoid replacing these with non-semantic elements like <div> or <span> with onclick, there are cases where they are necessary.

In these cases, custom controls should be made keyboard accessible. Every interactive element must receive keyboard focus, and the focus indicator should never be removed without a replacement. Tab order should follow the visual layout, avoiding confusion.

Custom components such as dropdown menus or sliders require manual keyboard support. Developers must ensure these components respond to Tab, arrow keys, and Escape. Avoid keyboard traps, where focus gets stuck inside an element.

Common mistakes to avoid

When working to improve keyboard access, steer clear of these common pitfalls:

  • Removing focus indicator with outline: none
  • Using positive tabindex values that break logical order
  • Making non-interactive elements focusable
  • Forgetting keyboard support for custom dropdowns
  • Creating focusable elements with no purpose
  • Designing other features that are not accessible via the keyboard

Testing keyboard accessibility

Organizations can take different approaches to testing keyboard accessibility. The most reliable strategy is to obtain an audit from a reputable, third-party accessibility experts, including native users of keyboard navigation. Automated scanning tools can be helpful in identifying common WCAG violations quickly across a large number of pages. However, automation can’t detect all barriers, including many keyboard accessibility issues that only manual testing can reveal.

If you want to perform a quick spot-check yourself, you can disconnect your mouse, open a new tab on your web browser, and try navigating with only the keyboard. Does every interactive element receive focus, and is the focus indicator always visible? Does focus move in a logical order, matching the visual layout?

Pay particular attention to keyboard traps, where focus gets stuck. Modal dialogs should trap focus until closed, and pressing Escape should dismiss them.

You should also test websites across different operating systems and browsers. For instance, macOS offers a keyboard setting to make all interactive elements keyboard-accessible. If you’re using Safari on macOS, you’ll need to enable a setting that allows the Tab key to reach interactive elements.

Key questions for spot-checking keyboard accessibility

As you check over a web page for keyboard accessibility barriers, bear in mind the following questions:

  • Can you Tab to every interactive element?
  • Is the focus indicator visible on each focused element?
  • Does the focus indicator have sufficient contrast?
  • Does focus order match the visual layout?
  • Can you activate all buttons and links with Enter or Spacebar?
  • Do modal dialogs trap focus until closed?
  • Does using the Escape key make dialogs close automatically?
  • Are there any keyboard traps?

Build keyboard navigation into every interaction

Supporting keyboard navigation is fundamental to providing accessible web experiences. By ensuring that elements receive focus, that focus moves logically, and that all interactions work using a keyboard, developers can build inclusive digital content that not only aligns with web accessibility standards, but ultimately meets real user needs.

Wondering whether your digital experiences are accessible to keyboard users? Our team can help you surface any existing barriers, and put together an actionable plan for addressing them. Learn more about our auditing and testing solutions, or contact our team to get started providing seamless journeys for every user.

Frequently asked questions

What is basic keyboard navigation?

Basic keyboard navigation lets users move through a web page using only the keyboard. The Tab key moves focus forward through interactive elements like links, buttons, and form controls. Shift + Tab moves focus backward. The Enter key activates links and buttons, while the Spacebar toggles checkboxes and activates buttons. Arrow keys help users navigate within components like dropdown menus and radio buttons.

Keyboard-only navigation means browsing websites without using a mouse or pointing device. Users rely entirely on the keyboard to move through web pages, click links, fill out forms, and interact with all page elements. Many users with motor disabilities, visual disabilities, or repetitive strain injuries depend on keyboard-only navigation or alternative input methods.

Press Tab to move forward through focusable elements on a web page. Identify the focus indicator to determine which element is active. Press Enter to activate links or Spacebar for buttons and checkboxes. Use arrow keys to navigate inside menus, radio buttons, and tab panels. Press Escape to close modal dialogs and popups. Use Shift + Tab to move backward through the page.

A keyboard focus indicator is a visible outline that shows which element currently has keyboard focus. Most browsers display a default focus indicator as a colored border around the focused element. This helps keyboard users understand exactly where they are on the page. Without a visible focus indicator, users cannot tell which button, link, or form field will respond to their keyboard input.

Yes, keyboard accessibility is required under several laws. Title II of the ADA mandates that state and local government websites and mobile apps conform with WCAG 2.1 Level AA, which covers keyboard access. Meanwhile, Section 508 uses WCAG 2.0 Level AA as the conformance standard for federal agencies. Additionally, courts have repeatedly ruled that websites must be fully accessible to keyboard users under ADA Title III, which applies to private businesses.

No, you should never remove the focus indicator completely. Removing focus styles with CSS outline: none creates a serious accessibility issue for keyboard users. They cannot understand where they are on your web page. Instead, style the focus indicator to match your design. Use a custom outline color, background change, or border that provides 3:1 contrast between the active element and the surrounding elements while keeping focus visible.

A keyboard trap occurs when keyboard users can Tab into an element but cannot Tab out. They get stuck and cannot reach the rest of the page. Certain types of dialogs and embedded content often cause keyboard traps. To avoid them, make sure users can always exit any component using the Tab key or Escape key. Test your site by navigating with only your keyboard to find traps before your users do.

The most reliable way to test your website for keyboard accessibility is to engage a reputable third-party expert to conduct a manual audit. This audit should include evaluation by native users of keyboard-only navigation. However, you can perform a quick check by unplugging your mouse and trying to navigate your website using only your keyboard.

Share