2.1.1 Keyboard

Many people cannot use a mouse. They navigate using a keyboard, a switch device, voice control, or other assistive technology that emulates keyboard input. If a feature only works with a mouse, it is inaccessible to all of them.

The requirement covers all functionality: not just navigation, but also interactive controls, drag-and-drop operations, custom widgets, media players, and anything else a user might interact with.

The exception is for functionality where the path of movement itself is essential, such as freehand drawing. If the function requires tracking where a pointer moves continuously, keyboard equivalence may not be possible.

Test every feature using only the keyboard. Use Tab to move forward between interactive elements, Shift+Tab to move backward, Enter or Space to activate buttons and links, and arrow keys for controls like sliders, radio buttons, and menus.

Custom components built from non-semantic HTML (divs and spans styled as buttons or menus) must have keyboard support added explicitly. Native HTML elements get this for free.

Drag-and-drop interfaces must have an alternative mechanism. A button that moves an item up or down in a list is a simple alternative to dragging.

• Dropdown menu that only opens on mouse hover, with no keyboard trigger
• Drag-and-drop file uploader with no keyboard alternative
• Custom slider built from a div with no keyboard event handling
• Modal dialog that cannot be closed with the keyboard

Some complex widgets require specific keyboard interaction patterns. A date picker, for example, should use arrow keys to navigate the calendar. The ARIA Authoring Practices Guide defines expected keyboard behaviour for common widget types.