// Accessibility
Keyboard navigation is the ability to reach, understand, and operate a website's interactive content through a keyboard interface without relying on pointer movement. `Tab` and `Shift` + `Tab` commonly move between controls, while keys such as Enter, Space, arrows, and Escape operate a control according to its type. WCAG 2.2 requires functionality to be keyboard-operable except where the path of the user's movement is essential to the input, such as freehand drawing.
Why it matters: Start with native links, buttons, and form controls because browsers provide their expected focus and keyboard behaviour. Keep the DOM and focus sequence logical, avoid positive `tabindex` values, show a persistent focus indicator, and ensure sticky content does not hide the focused control. Users must be able to leave every component; dialogs and menus need deliberate focus entry, movement, dismissal, and return. Custom widgets need both correct semantics and the keyboard pattern expected for that widget—ARIA alone does not add behaviour. Test complete tasks using only the keyboard, in both directions, including navigation, forms, validation, disclosures, carousels, menus, dialogs, media, and dynamically added content. Then test separately with relevant assistive technologies. A control can be visible yet unreachable or inoperable by keyboard, and passing a keyboard test alone does not establish WCAG conformance.
Explore related checks and guidance for keyboard navigation on your own site.
Open Accessibility AgentLooking for practical context? Start with the guidance behind these checks and definitions.
Explore accessibility guidance