Skip to main content
Votre navigateur est trop ancien pour afficher correctement ce site. Veuillez passer à la dernière version de Chrome, Edge, Firefox ou Safari.
Back to WCAG Database
Level AWCAG 2.0

2.1.1 Keyboard

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

Last reviewed: September 9, 2026

Understanding 2.1.1

The intent of this Success Criterion is to ensure that, wherever possible, content can be operated through a keyboard or keyboard emulator. This is crucial for users with visual impairments who use screen readers, and users with motor disabilities who rely on keyboards or switch devices.

How to Meet It

Ensure all interactive elements (links, buttons, form fields) are natively focusable. If building custom widgets, ensure they can receive focus (using `tabindex="0"`) and respond to standard keyboard events (Enter/Space to activate, Arrow keys to navigate).

Code Examples

INCORRECT
<div onclick="submitForm()" class="btn">Submit</div> <!-- Cannot receive focus, cannot be triggered via keyboard -->
CORRECT
<button type="button" onclick="submitForm()" class="btn">Submit</button> <!-- Natively accessible -->

Frequently Asked Questions

Can I use tabindex > 0 to fix the tab order?

No. Using positive tabindex values (like tabindex="1") creates a brittle and unpredictable focus order that often breaks the logical flow of the page. You should arrange the HTML source code to match the visual layout.

Related Success Criteria

2.1.2 No Keyboard Trap2.1.3 Keyboard (No Exception)2.1.4 Character Key Shortcuts

Quick Facts

  • Criterion2.1.1
  • LevelA
  • IntroducedWCAG 2.0

Automate Compliance

AccessiSight automatically scans and identifies 2.1.1 issues in your codebase.

Try Scanner Free