Skip to main content
사용 중인 브라우저가 오래되어 이 사이트가 제대로 표시되지 않습니다. Chrome, Edge, Firefox 또는 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