Keyboard Navigation: The Tractor That Plows Every Field
Updated
Not everyone drives the same equipment
Watch someone navigate a well-built website with just a keyboard. Tab, Tab, Enter. Arrow keys through a menu. Space to toggle a checkbox. It's efficient, deliberate, and, when the site is built right, seamless.
Now watch someone try the same thing on a site that wasn't built for it. The focus indicator vanishes. Tab lands on invisible elements. Interactive buttons do nothing when you press Enter. The tractor stalls in the middle of the row.
Who navigates by keyboard?
The list is longer than most developers assume. Screen reader users navigate almost entirely by keyboard. People with motor disabilities may use switch devices or alternative input that maps to keyboard events. Power users prefer keyboard shortcuts for speed. Anyone with a temporary injury (a broken wrist, a sprained thumb) suddenly needs what they never thought about before.
Keyboard accessibility isn't a niche concern. It's a fundamental interface contract: if an element is interactive, it must be operable without a pointing device.
The three pillars
Focusable
Every interactive element needs to receive focus. Native HTML buttons, links, and form inputs get this for free. Custom components built from div and span elements do not. If you're building a custom dropdown or modal, you need tabindex="0" at minimum, and appropriate ARIA roles to communicate what the element actually does.
Visible
Focus indicators are the headlights on your tractor. Remove them and you're plowing blind. CSS declarations like outline: none without a replacement are one of the most common accessibility failures on the web. Style your focus indicators. Make them match your brand, but never remove them entirely.
Operable
A focused element must respond to expected key presses. Buttons activate on Enter and Space. Links navigate on Enter. Custom widgets like tabs, accordions, and menus should follow the WAI-ARIA Authoring Practices for their keyboard patterns. When users press a key and nothing happens, trust evaporates.
Common failures we find
In our work with eiSEO, keyboard issues rank among the most frequent WCAG violations. The usual suspects:
- Click handlers on
divelements with no keyboard equivalent - Focus traps that lock users inside a modal with no way out
- Dropdown menus that open on hover but have no keyboard trigger
- Carousels that auto-advance with no pause control
- Skip links that are present in HTML but hidden in a way that prevents focus
Test it yourself
Put your mouse in a drawer. Navigate your own site using only Tab, Shift+Tab, Enter, Space, Escape, and arrow keys. Can you reach every link? Activate every button? Open and close every menu? Fill out every form?
If you get stuck anywhere, your keyboard-dependent users get stuck there too. The tractor only works if it can reach every row in the field, not just the ones closest to the barn.