SiteLint documentation and guidelines

Verify keyboard accessibility

Description

Keyboard accessibility ensures that all interactive elements on a page can be reached using the Tab key and fully operated using the keyboard alone, typically with Enter, Space, or arrow keys. This includes links, buttons, form controls, custom widgets, and other interactive components.

If an element cannot receive keyboard focus or cannot be activated without a mouse or touch input, users who rely on keyboards or assistive technologies may be unable to interact with essential functionality. This violates WCAG Success Criterion 2.1.1, which requires that all functionality be operable through a keyboard interface.

Disabilities impacted

  • Motor impairments: users who cannot use a mouse and rely on a keyboard, switch devices, or alternative input methods need full keyboard operability.
  • Visual impairments: screen reader users primarily navigate using the keyboard and depend on proper focus behavior and keyboard interaction.
  • Cognitive disabilities: predictable keyboard navigation and interaction reduces confusion and improves usability.

Why it matters

Many users cannot use a mouse due to physical, visual, or temporary impairments. Ensuring that interactive elements are reachable via Tab and usable with standard keyboard commands allows these users to complete tasks such as submitting forms, opening menus, or activating controls.

Keyboard accessibility also improves overall usability, supports assistive technologies, and helps ensure compliance with accessibility standards and legal requirements.

Coding problems and solutions

Common coding problems

  • Non-focusable interactive elements: clickable elements such as <div> or <span> without keyboard focus support.
  • Mouse-only event handlers: interactions implemented using onclick without equivalent keyboard event handling.
  • Missing keyboard interaction logic: custom components that cannot be activated using Enter or Space.
  • Focus traps: keyboard users cannot move focus into or out of a component such as a modal or menu.

How to fix it

Use native interactive elements

Native HTML elements such as <button>, <a>, and form controls are keyboard-accessible by default and should be used whenever possible.

Incorrect example

<div onclick="submitForm()">Submit</div>
Correct example

<button type="button" onclick="submitForm()">Submit</button>

Make custom elements focusable and operable

If custom elements must be used, ensure they can receive keyboard focus and respond to keyboard input.

Incorrect example

<div class="menu-item" onclick="openMenu()">Menu</div>
Correct example

<div
  class="menu-item"
  role="button"
  tabindex="0"
  onclick="openMenu()"
  onkeydown="if (event.key === 'Enter' || event.key === ' ') openMenu();"
>
  Menu
</div>

Ensure logical tab order

Keyboard focus should move through interactive elements in a logical and predictable order that matches the visual layout.

Incorrect example

<button tabindex="3">Save</button>
<button tabindex="1">Cancel</button>
<button tabindex="2">Next</button>
Correct example

<button>Cancel</button>
<button>Next</button>
<button>Save</button>

Known limitations

  • Complex custom widgets: components such as sliders, carousels, or menus require careful keyboard interaction design and testing.
  • Third-party components: some third-party libraries may not fully support keyboard accessibility and may require customization.
  • Automated testing limits: automated tools can detect focus issues but may not verify all keyboard interactions; manual testing is essential.

Resources

Rule

  • Rule ID: verify-keyboard-accessibility.
  • Standard: Accessibility, WCAG 2.1.1 (Keyboard).