3 minute read

WCAG 2.1.1: Keyboard (Level A)

There are lots of reasons you might need to navigate a website without a mouse—maybe it needs charging, or it somehow just wasn’t in your laptop bag this morning.

For people who rely on keyboards to get around the web, this is a daily reality.

Keyboard guarantees that all the essential functions of a website can be operated using only the keyboard, making sure no one is left stranded just because they don’t use a mouse.

Who this impacts

  • People with motor impairments: Users who rely on a keyboard to navigate must be able to interact with all site elements without needing a mouse.
  • People using assistive technologies: Screen readers and other assistive tools rely heavily on keyboard functionality to interact with websites.
  • People using non-traditional devices: Not everyone uses a mouse—some users rely on keyboards for navigation or may use alternative devices (like buttons pressed with their head or feet) that simulate keyboard input.
  • Everyone: Situational needs—like a broken mouse or multitasking—make keyboard accessibility useful for everyone at some point.

How to meet Keyboard

  1. Make all functionality keyboard-accessible: Ensure that every interactive element—such as links, buttons, and form fields—can be accessed and activated using only a keyboard.
  2. Use logical focus order: Ensure the focus moves logically through elements to create a smooth, predictable navigation experience.
  3. Avoid keyboard traps: Users must be able to move through all interactive elements using keyboard navigation (such as the Tab key), and they should not get “trapped” in any element without a way to move forward or back.

Practical example

The Catbook website ensures that all forms, buttons, and navigation links can be accessed using keyboard navigation. The focus indicator makes it clear where the user is on the page, and they can easily navigate through menus and forms without getting trapped.

Exceptions

When certain actions are inherently reliant on non-keyboard input—like drawing in a design tool—keyboard-only access may not be required. However, alternative options should be provided when possible.

Top tips

  • Design for keyboard access from the start: Plan and test your site’s interactivity with keyboard navigation in mind to ensure smooth access for all users.
  • Use consistent navigation patterns: Keep navigation order logical and predictable, so users know what to expect as they tab through content.
  • Look out for traps: Ensure there are no points on the site where users get trapped in an element with no way to move forward or back using just the keyboard.
  • Use Eric Kroes’ Universal Focus State:  Here’s a link to the Oreo Cookie focus state, so you can have an instant solution that works.

Further reading

Previous articleNext article
Back to top