"Keyboard-only user" is a category most teams treat as an edge case. In practice it covers a lot more people than the stereotype suggests, and most sites fail them in the first thirty seconds.
Who actually uses keyboard-only
The stereotype is a blind user with a screen reader. That user exists and matters. They are not most of the population who rely on keyboard navigation.
- Motor disabilities. RSI, arthritis, tremor, low-precision pointer control. Many of these users have functioning vision but cannot reliably use a mouse or trackpad.
- Temporary injuries. Broken wrist, carpal tunnel flare-up, sore hand from a day of gaming. Lasts weeks. Uses the web the whole time.
- Power users. Engineers, writers, designers, traders who prefer keyboards because they are faster. If the site breaks their flow, they leave.
- Voice control users. Dragon NaturallySpeaking, Voice Access on Android, Voice Control on macOS. All of these drive the page via keyboard-equivalents underneath. If keyboard nav is broken, voice is broken.
- Switch users. People with severe motor impairments who navigate with one or two large buttons. Their inputs resolve down to tabbing.
- Mobile keyboard users. External Bluetooth keyboard on a tablet. Accessibility setting that enables full keyboard access on iOS. Not uncommon.
The actual population of keyboard-dependent visitors is dominated by the middle three categories, not the stereotype.
The common failures
Every failure below is present in common web patterns as of 2025.
- Focus invisible or barely visible. Custom styles strip the default outline and don't replace it. A keyboard user presses Tab and has no idea where they are.
- Focus traps in modals. Modal opens. Focus enters. Tab then exits back into the page underneath. The user is now navigating the wrong content.
- Route changes in SPAs. Click a link. URL changes, content changes, but focus stays on the link. Screen reader reads old content. Next Tab sends focus to the wrong next element.
- Skip links that don't work. The link is present. The target is not focusable. Pressing Enter on "skip to main content" does nothing keyboard-visible.
- Custom components that ignore keyboard semantics. Dropdowns that only open on click. Tabs that don't support arrow keys. Sliders that don't respond to Home and End.
- Sticky headers obscuring focused content. Element receives focus, scrolls into view, lands behind the sticky header. The keyboard user sees nothing.
Each one is a small failure. Ten of them accumulate into a site that is unusable by keyboard.
Why automated testing misses most of this
Automated accessibility tools can check for visible focus outlines, reachable focusable elements, and a handful of common patterns. They cannot check whether the focus order is logical. They cannot check whether the focus target makes sense after a modal closes. They cannot check whether a sticky header is obscuring focused content.
The set of problems that matters here is exactly the set that needs a human pressing Tab.
What actually fixes it
Not more tooling. A morning with your mouse disconnected.
Actually use the site with only the keyboard. Every team that does this once finds real problems within ten minutes. Most of those problems aren't listed in any audit. They are in the gap between "pass" and "usable."
The frame shift
Stop thinking of keyboard-only as an accommodation for a small population. Think of it as the baseline mode of operation that every other input method builds on.
Voice control is keyboard-equivalent underneath. Switch access is keyboard-equivalent underneath. Assistive tech is keyboard-equivalent underneath.
If keyboard doesn't work, nothing else does either.