UX glossary · engl. Keyboard Accessibility
Keyboard Accessibility
Keyboard accessibility means a website or app can be used entirely without a mouse. For many disabled people, it’s what makes a product usable in the first place.
Imagine you want to order something from an online shop, but your hand is in a cast after an injury. Using a mouse is out, so you press the Tab key. A frame jumps through the menu, then vanishes somewhere inside a banner. You can no longer see which button is active. The shopping cart stays out of reach.
Keyboard accessibility is about preventing exactly that.
Explained simply
Keyboard accessibility means a website or app can be used entirely without a mouse or touchscreen. Think of a building with both stairs and a lift: everyone can get in. If there are only stairs, some people stay outside. For many digital products, the keyboard is that lift.
The people who rely on it include those with motor impairments, people who use a screen reader, and anyone working with adapted keyboards, switches or voice control. Plenty of power users simply prefer the keyboard because it’s faster.
The key controls are quick to explain. Tab moves you to the next interactive element, Shift and Tab move you back. Enter activates links and buttons, the space bar activates buttons and checkboxes. The arrow keys move you within menus, radio buttons or tabs, and Escape closes dialogs.
What WCAG requires
The WCAG (Web Content Accessibility Guidelines) turn this into testable criteria. The most important ones:
- 2.1.1 Keyboard (Level A): Every function must work with a keyboard. The only exception is functionality where the path of movement matters, such as freehand drawing.
- 2.1.2 No Keyboard Trap (Level A): Focus must never get stuck. You have to be able to leave every element again.
- 2.4.7 Focus Visible (Level AA): It must be clear which element currently has focus, meaning which one will respond to your input.
- 2.4.11 Focus Not Obscured (Minimum) (Level AA, new in WCAG 2.2): The focused element must not be completely hidden by content such as sticky headers or cookie banners.
On top of that, 2.4.1 Bypass Blocks (Level A) says repeated blocks like the navigation must be skippable. The most common solution is a skip link, a “Skip to content” link that appears on the first press of Tab and takes you straight to the main content.
An example
Here’s an example: a booking portal builds its date picker from clickable div elements. You can’t reach it with Tab at all, and the focus outline was removed in CSS with outline: none because it looked “ugly.” For anyone without a mouse, the booking ends right there.
After the redesign, the days are real buttons, the arrow keys move between them, and a bold focus outline in the brand color shows where you are. The function is the same, but now everyone gets there. Why details like these matter is covered in Why Accessibility Is More Than Contrast and Font Size.
In practice
- Put the mouse away. Run through your key flows using only Tab, Enter, the space bar and Escape. It takes minutes and uncovers a lot of problems.
- Use native elements. Real buttons, links and form fields work with the keyboard out of the box. Custom components need extra keyboard handling and often ARIA.
- Style the focus instead of removing it. A clearly visible focus outline belongs in your design system. More testing methods are in Accessibility Testing: Tools and Methods for UX Designers.
Related terms
Accessibility, WCAG, Screen Reader, ARIA