Keyboard Navigation and Alternative Input
Mice are optional. That's the thing to hold onto.
For some people, using a mouse or trackpad is physically difficult or impossible — motor disabilities, tremors, limited hand mobility, or limb differences can all make pointer-based interaction unreliable or inaccessible. For others, a keyboard is simply faster or more comfortable. For others still, the "keyboard" isn't a keyboard at all — it's a switch, an eye tracker, or a voice control system that maps commands to keystrokes. All of them share a common requirement: your site needs to be fully operable without a mouse.
If something only works by clicking, it doesn't work.
How keyboard navigation works
The basic model is simple. Tab moves focus forward through interactive elements — links, buttons, form inputs, anything that can be activated. Shift + Tab moves backward. Enter and Space activate whatever has focus. Arrow keys navigate within components: moving between options in a menu, between items in a radio group, adjusting a slider.
That's the full toolkit for most keyboard users. It's not a degraded experience — it's a complete one, as long as the page is built to support it.
One important thing to notice: keyboard focus follows DOM order, the same source order that screen readers use. A layout that looks organized visually but has elements in an unexpected order in the HTML creates problems for both audiences at once. Getting structure right tends to fix multiple things simultaneously.
Focus indicators
When you navigate with a keyboard, you need to know where you are. Focus indicators are the visual signal that answers that question — the outline, highlight, or other marker that shows which element currently has focus.
Without a visible focus indicator, keyboard navigation is like using a mouse with an invisible cursor. You can keep pressing Tab and things will happen, but you have no idea what you're about to activate or where you are on the page.
Focus indicators get removed constantly. The usual reason: the default browser outline looks out of place in a polished design, and :focus { outline: none; } is a quick fix that gets committed and forgotten. It is also, straightforwardly, an accessibility failure — one that WCAG explicitly calls out.[1]
The right response isn't to restore the default browser ring and call it done. It's to design a focus indicator that fits the visual language of the site while meeting the contrast and size requirements that make it actually useful. A well-designed focus state is part of the design, not an afterthought.
Tab order
By default, tab order follows the order elements appear in the DOM — top to bottom, in source order. This works well when visual layout and HTML order match. It gets confusing fast when they don't.
A common scenario: a two-column layout where the sidebar comes first in the HTML for styling reasons, even though visually it sits on the right. A keyboard user tabbing through the page hits all the sidebar links before they reach the main content. The visual experience and the keyboard experience tell different stories about how the page is organized.
tabindex is the attribute that controls focus order, and it's mostly a trap. Setting tabindex="0" makes a non-interactive element focusable (useful for custom components). Setting tabindex="-1" removes an element from the tab sequence but keeps it programmatically focusable (useful for managing focus in JavaScript). Setting tabindex to any positive integer — tabindex="2", tabindex="5" — overrides the natural order and almost always creates more problems than it solves. The better fix for a broken tab order is almost always fixing the DOM order.
Skip links
Every time a keyboard user loads a new page, they start at the top. If your site has a navigation menu with twelve links, that's twelve Tab presses before they reach the main content — on every single page.
Skip links solve this. A skip link is typically the first focusable element on the page: a link that jumps focus directly to the main content when activated. Most of the time it's visually hidden until it receives focus, at which point it becomes visible so keyboard users can see and use it.
It's one of the simpler accessibility wins available, and it has an outsized effect on usability. A keyboard user who discovers your site has a working skip link has a fundamentally different experience than one who has to Tab through your entire header on every page.
Alternative input devices
Keyboard navigation is the foundation, but the population it serves extends well beyond people using physical keyboards.
Switch access — a switch is a single button, activated by hand, foot, head movement, or breath. Switch users typically scan through options automatically — the interface cycles through focusable elements and they activate the one they want when it's highlighted. Anything that works by keyboard generally works for switch users; anything that requires speed, precision timing, or hovering does not.
Eye tracking — eye-tracking systems allow users to control a cursor with their gaze. This can emulate both pointer and keyboard input depending on the software. Targets that are too small or too close together create real barriers.
Voice control — software like Dragon NaturallySpeaking (or the built-in voice control on macOS and iOS) lets users speak commands to navigate and interact. Voice control users often navigate by saying the visible label of an element: "click Submit," "tab to Search." When a button has no visible label, or when its accessible name doesn't match what's visible, voice control breaks down.
The thread connecting all of these: they rely on the same accessible structure that keyboard navigation requires. A well-structured, keyboard-accessible page works better for all of them. The reverse is also true.