Free community resource
WCAG 2.1.1

Keyboard Navigation

WCAG criteria

Keyboard navigation is the ability to operate all functionality on a web page
using only a keyboard, without requiring a mouse or pointer device. It is a
fundamental requirement for users with motor disabilities, power users, and
anyone using assistive technology such as a screen reader.
[1]


Why it matters

Many users cannot use a mouse. This includes people with motor impairments,
tremors, repetitive strain injuries, and those using switch access devices or
eye-tracking software. All of these users depend on keyboard-operable interfaces.
[2]

Screen reader users also navigate primarily by keyboard. An interface that
fails keyboard users fails screen reader users too.


Core keyboard interactions

Key Action
Tab Move focus to next interactive element
Shift + Tab Move focus to previous interactive element
Enter Activate links and buttons
Space Activate buttons, toggle checkboxes
Arrow keys Navigate within components (menus, tabs, sliders)
Escape Close dialogs, dismiss menus
Home / End Jump to first or last item in a list

What must be keyboard accessible

WCAG 2.1.1 requires that all functionality available via mouse is also available
via keyboard, unless the functionality requires a path-dependent input (such as
freehand drawing).
[1]

This includes:

  • All links and buttons
  • All form controls
  • Custom widgets (dropdowns, date pickers, carousels)
  • Modal dialogs and overlays
  • Drag and drop interfaces (must have a keyboard alternative)

Common failures

onclick-only handlers. Attaching interaction only to click events excludes
keyboard users. Always pair click handlers with keydown handlers for Enter and
Space, or use a native button element which handles this automatically.

Positive tabindex values. Using tabindex values greater than 0 overrides the
natural DOM tab order and creates a confusing navigation experience. Use
tabindex="0" to add an element to the tab order, or tabindex="-1" to allow
programmatic focus only.
[3]

Mouse-only events. mouseover, mouseout, and mousemove events have no keyboard
equivalent. Always provide keyboard-accessible alternatives for any functionality
triggered by these events.


Testing keyboard accessibility

  1. Unplug or disable your mouse
  2. Tab through the entire page from top to bottom
  3. Verify every interactive element receives visible focus
  4. Verify every action can be triggered with Enter or Space
  5. Verify no focus gets trapped unexpectedly
  6. Verify dialogs and menus can be closed with Escape

References

  1. W3C Web Accessibility Initiative. Understanding Success Criterion 2.1.1: Keyboard. https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html
  2. W3C Web Accessibility Initiative. Keyboard Compatibility. https://www.w3.org/WAI/perspective-videos/keyboard/
  3. W3C Web Accessibility Initiative. Understanding Success Criterion 2.4.3: Focus Order. https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html

Last edited Apr 5, 2026, 7:12 PM · P**** J****