Keyboard-Only Navigation: Can Anyone Use Your Site Without a Mouse?

Here is a usability test that costs nothing, requires no software, and takes five minutes. Put your mouse out of reach. Open your website. Now buy something, or sign up, or do whatever it is you most want visitors to do — using only the keyboard. Tab to move forward, Shift-Tab to move back, Enter to activate, arrow keys and Space where they make sense. Most site owners have never tried this on their own product. Most who try it fail it.

I want to explain why this test matters so much, because on its face it sounds like a parlor trick. Who browses without a mouse? More people than you’d think, and for more reasons than you’d think. There are people with motor impairments — tremors, limited hand control, repetitive strain injuries — for whom precise pointing is somewhere between painful and impossible. There are blind users, whose screen readers are driven entirely from the keyboard, since you can’t aim a cursor at something you can’t see. There are people using switch devices, sip-and-puff controllers, and voice control systems, nearly all of which work by generating the same events a keyboard does. And there are power users with two working hands who simply find tabbing through a form faster than reaching for the mouse between every field. The keyboard is not one input method among many. It’s the load-bearing layer that most assistive technology is built on top of. When keyboard access breaks, everything stacked on it breaks too.

The web, left alone, passes this test. That’s worth pausing on. A plain HTML page — links, buttons, form fields — is keyboard-accessible by default. Browsers have handled Tab order, focus, and Enter-to-activate since the nineties. Nobody has to build keyboard support. What people build, energetically and by accident, is keyboard breakage. It arrives in a few standard ways, and once you know them you’ll see them everywhere.

The first is the fake button. Somebody attaches a click handler to a div or a span instead of using a real button element. It looks identical and works fine with a mouse. But a div isn’t focusable — Tab skips right over it — and even if you force it to be, Enter does nothing, because only real buttons and links get keyboard activation for free. The control exists for mouse users and simply doesn’t exist for anyone else.

The second is the murdered focus outline. When you Tab through a page, the browser draws a ring around whatever currently has focus, so you know where you are. Designers find it ugly, and one line of CSS — outline: none — removes it. This is the equivalent of turning off the cursor and asking people to keep typing. Everything still technically works; you just can’t see where you are, so in practice nothing works. If the default ring clashes with your design, style it. Making it invisible isn’t styling, it’s amputation.

The third is the trap. A modal dialog opens, and either focus never moves into it — you’re tabbing through the dimmed page behind it, invisibly — or focus gets in and can’t get out, and the Escape key that should close it does nothing. Whole sessions end inside a cookie banner this way.

Notice what these have in common: each one is extra work. The accessible version — a real button, the default focus behavior, a dialog built on standard patterns — was less code. Keyboard accessibility is one of the few qualities in software that you get by doing less. Sites don’t fail the tab test because accessibility is expensive. They fail it because someone rebuilt, with effort, what the browser already provided, and rebuilt it worse.

The business case is not abstract. Every keyboard failure sits somewhere on your site, and the odds are decent it sits on the path to money — checkout flows and signup forms are dense with custom controls, dropdowns, date pickers, the exact components most likely to be fake. A visitor who can’t reach your buy button doesn’t file a bug report. They leave, and they were often the easiest sale you had, because a person navigating your checkout by keyboard has already decided to buy. You’re not losing browsers. You’re losing buyers at the last step.

This is also one of the areas where I’ll admit automated tools, mine included, have limits. GazeSite can detect the telltale signs in the HTML — click handlers on non-interactive elements, missing focus styles, controls that can’t receive focus — and those signals are worth acting on. But nothing substitutes for the experience of actually being stuck: tabbing toward a button that never comes, or losing your place because the focus ring is gone. The five-minute test gives you that experience firsthand, and it changes how you build afterward.

So do it today. Unplug the mouse, open the site, try to buy the thing. Where you get stuck, a customer gets stuck. Where you get lost, a customer gets lost. The difference is that you’ll fix it, and they would have just left.