Unplug Your Mouse: What Keyboard-First Testing Teaches You About Your App

A few winters ago, one of the sharpest engineers I've ever worked with came back from a ski trip with his right wrist in a cast. For six weeks, he navigated everything — Slack, Jira, our own product — with a keyboard and nothing else. By the end of the first week he had filed fourteen bugs against our app. Not obscure edge cases. Core flows. He couldn't dismiss the onboarding modal. He couldn't reach the date picker in reports. He tabbed into the footer once and genuinely could not figure out how to get back out.

Here's the part that stuck with me: none of those bugs were new. Every one of them had been shipping for months. We just never used the product the way he suddenly had to.

That experience changed how I test, and it's the single habit I recommend most to engineers who want to get better at accessibility: before you reach for a screen reader, an audit tool, or a checklist, put your mouse out of reach and try to use your own feature.

The keyboard is the canary

Keyboard access isn't one niche input method — it's the foundation that a whole family of assistive technologies is built on. Screen readers drive the page through keyboard-style navigation. Switch devices, sip-and-puff controllers, and many voice control setups ultimately map onto the same focus and activation model. Then there are people with tremors, RSI, or a temporary injury like my teammate's — and honest power users who just prefer it.

So when something breaks for the keyboard, it usually breaks for all of those people at once. In my experience, somewhere around half of the accessibility issues that show up in a full audit are visible in the very first keyboard-only pass. That's a remarkable return on an investment of five minutes and zero tooling.

Start with the Tab key

Press Tab and watch where focus goes. Two questions matter: can you reach every interactive element, and does the order make sense?

Tab order follows DOM order, not visual order. That's usually fine — until CSS gets creative. Flexbox order, grid placement, and absolute positioning can all make the visual layout diverge from the source, and suddenly focus jumps from the search box to the footer and back up to the nav. Your eyes follow the layout; the keyboard follows the markup.

The tempting "fix" is sprinkling positive tabindex values around, and I'd gently steer you away from it every time:

<!-- Looks fine on screen; tab order is now managed by hand, forever -->
<div class="toolbar">
  <button tabindex="3">Save</button>
  <button tabindex="1">Edit</button>
  <button tabindex="2">Share</button>
</div>

<!-- Let the DOM define the order -->
<div class="toolbar">
  <button>Edit</button>
  <button>Share</button>
  <button>Save</button>
</div>

Positive tabindex yanks elements to the front of the tab order ahead of everything else on the page, and every future change has to be renumbered around it. If the tab order feels wrong, the honest fix is almost always reordering the DOM to match the visual flow.

Can you see where you are?

Reaching an element is only half the deal — you also need to know you've reached it. That's what the focus indicator is for, and it's astonishing how often it's been deliberately removed because somebody found the default ring ugly.

/* The classic crime */
:focus {
  outline: none;
}

/* The modern fix: a ring for keyboard users, none for mouse clicks */
:focus-visible {
  outline: 2px solid #4c9aff;
  outline-offset: 2px;
}

:focus-visible resolved the old design-versus-accessibility standoff years ago: browsers show it for keyboard navigation and suppress it for most mouse interactions. There's no longer a reason to ship an invisible focus state. If the default ring clashes with your design, style it — make it bolder, on-brand, beautiful. Just make it visible, ideally with strong contrast against whatever it sits on.

When you do your keyboard pass, narrate it to yourself: "I can see I'm on Search. Now I'm on Filters. Now I'm... somewhere?" The moment you lose track of focus, you've found a bug.

Traps and dead ends

The third thing a keyboard pass catches is places you can get stuck — or places you can never get into at all.

A keyboard trap is anywhere focus enters and can't leave: a modal with no Escape handling, an embedded rich-text editor that swallows Tab, a custom widget that loops focus among its own children forever. WCAG calls this out explicitly because it's so severe — for a keyboard-only user, a trap doesn't degrade the page, it ends it.

The reverse trap is quieter and, lately, a lot more common: interactive things you can't reach at all. A <div> with a click handler is invisible to the Tab key — focus skips right over it as if it were a paragraph. I see this constantly in AI-generated components now. The code looks polished, the styling is lovely, and the "button" is a styled div that only a mouse can operate. This is exactly the kind of thing a reviewer catches in thirty seconds of keyboard testing and almost never catches by reading the diff alone, because the rendered result looks perfect.

Also watch what happens when elements disappear. Delete a list item while it holds focus and, in many apps, focus silently drops to <body> — the keyboard user is teleported to the top of the page with no explanation. Move focus somewhere sensible on removal: the next item, or the list's heading.

A five-minute keyboard audit

Here's the routine I actually run, and the one I nudge teammates to run before requesting review on any UI change:

1. Put the mouse physically out of reach. (Willpower is not a testing strategy.)
2. Tab through the whole page. Can you reach everything you could click?
3. At every stop, can you see where you are without guessing?
4. Does the order roughly follow the visual reading order?
5. Does Enter activate links and buttons? Does Space work on buttons and checkboxes?
6. Open every overlay — modal, dropdown, date picker. Can you operate it? Does Escape close it? Where does focus land when it closes?
7. Try to get out of everything you got into.

Five minutes, no tools, no expertise required — just a willingness to feel briefly clumsy in your own product.

Where to start on Monday

• Do one keyboard-only pass on the next feature you build, before you open the PR. You'll find something. Almost everyone does.
• Hunt down outline: none in your codebase and replace it with a styled :focus-visible.
• Treat any positive tabindex in a diff as a question: what DOM order problem is it papering over?
• In review, be suspicious of onClick on divs and spans — especially in generated code, where it's the default failure mode.
• When a component removes itself, decide where focus goes next. Silence is a bug.

Keyboard testing won't catch everything — you'll still want screen reader passes and automated checks in the mix. But it's the cheapest, fastest way I know to experience your app the way a lot of real people do, and it turns abstract "accessibility" into concrete bugs you can just... fix. My teammate got his cast off after six weeks. The habit he gave the rest of us never left.