--- title: "Keyboard navigation" category: accessibility status: required url: https://webspecification.com/spec/accessibility/keyboard-navigation/ updated: "2026-05-29T09:13:20.000Z" sources: - title: "WCAG 2.1.1 — Keyboard (Level A)" url: "https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html" publisher: "W3C" - title: "WCAG 2.1.2 — No Keyboard Trap (Level A)" url: "https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html" publisher: "W3C" - title: "WCAG 2.4.3 — Focus Order (Level A)" url: "https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html" publisher: "W3C" source_repo: undefined licence: CC-BY-4.0 --- # Keyboard navigation > Every interactive element on the page must be reachable and operable with a keyboard alone, in a logical order, with no traps that hold focus. ## What it is Keyboard navigation is the ability to reach and operate every control on a page using only a keyboard — Tab and Shift+Tab to move, Enter and Space to activate, arrow keys inside composite widgets, Escape to dismiss. Many users never touch a mouse: people using switch devices, screen readers, voice control, or just a laptop trackpad they find painful. ## Why it matters If a control can be clicked but not focused, it does not exist for a large share of disabled users. WCAG 2.1.1 (Level A) requires all functionality to be operable from a keyboard. 2.1.2 (Level A) requires that focus is never trapped — the user must always be able to move on. 2.4.3 (Level A) requires the focus order to preserve meaning and operability. ## How to implement The cheapest way to get keyboard support right is to use the right HTML element: ```html About ``` Native `