Engineering keyboard-first interfaces

Accountants live on the keyboard. So do support agents, warehouse staff, doctors between appointments, and everyone whose mouse hand is currently holding a coffee. When we rebuilt the Northwind Ledger dashboard, the single request that outnumbered all others was "make it fast from the keyboard" — and the speed the users meant wasn't milliseconds. It was never having to reach for the mouse.

Keyboard-first is usually filed under accessibility, where it will be audited, nodded at, and deprioritised. Reframe it as a performance feature for power users and it gets budget. Both framings are true; the second one ships. Here is the engineering playbook we run on dense product interfaces.

The trap most teams build first

The instinct is to add tabindex="0" to everything interactive-looking and call it done. The result is a tab order with 90 stops per screen, where reaching the main content requires the stamina of a pilgrim. Worse, the team concludes "keyboard support is tedious" and quietly abandons it.

The correct mental model comes from desktop software: Tab moves between regions, arrow keys move within them. A toolbar is one stop. A date grid is one stop. A list of a thousand rows is one stop. Get that right and a keyboard user crosses your dashboard in six keystrokes.

Roving tabindex, done properly

The pattern: within a composite widget, exactly one item has tabindex="0"; everything else has tabindex="-1". Arrow keys move the 0 around.

function moveFocus(items: HTMLElement[], current: number, delta: number) {
  const next = (current + delta + items.length) % items.length;
  items[current].tabIndex = -1;
  items[next].tabIndex = 0;
  items[next].focus();
}

The details that separate a demo from production:

• Wrap or don't wrap — decide per widget. Menus wrap (last item → first). Tab lists stop at the ends; wrapping there disorients.
• Home/End jump to the ends; Page Up/Down skip by page in long lists. These cost an evening to add and are the difference between "supported" and "loved".
• Type-ahead in lists. In a 400-row customer list, typing "mer" should move focus to Meridian. It's twenty lines of code and it's the feature users mention unprompted in feedback calls.
• Skip rendering rows nobody can see. Virtualised lists interact badly with roving tabindex because the focused row can scroll out of the DOM. Handle it: keep the focused index in state, and when focus enters the list after a scroll, restore focus to the row nearest the viewport, not a row that no longer exists.

Focus management without traps

The modal is where keyboard support goes to be graded. The contract has four clauses: focus moves into the modal on open, Tab cycles within it, Escape closes it, and focus returns to the element that opened it. Miss the last one and the user's focus is dumped at the top of the document — the modal equivalent of hanging up without saying goodbye.

function close() {
  setOpen(false);
  openerRef.current?.focus(); // recorded on open
}

The sins we find in nearly every audit: focus traps implemented with a global keydown listener that fights the browser's own tab order; "traps" that don't trap in both directions (Shift+Tab from the first element escapes silently); and focus sent to the modal container rather than to something meaningful inside it. Land on the close button or the primary action — a user who just opened "Delete invoice?" should be one keystroke from their choice, not a mystery tour.

Drawers, popovers and command palettes are all modals with worse marketing; they owe the same contract. Non-modal things (toasts, auto-suggest) must never steal focus at all — announce them with a polite live region and let Tab find them in the natural order.

Shortcuts people can actually discover

A shortcut system succeeds or fails on discoverability, which is a UX problem wearing an engineering costume. Our rules:

1. Single-letter shortcuts only when nothing is editable in context. Pressing e to edit is delightful on a read view and catastrophic in a form. Gate shortcuts with a check that focus is not in an input, textarea or contenteditable — the bug behind half of all "shortcuts ate my typing" complaints.
2. Chords over modifiers where the platform allows. GitHub's g d (go to dashboard) pattern scales to dozens of shortcuts without contorting fingers. Implement as a small state machine with a 1-second reset, not a bag of regexes.
3. Every shortcut must appear somewhere visible. Beside the menu item it accelerates, or in the ? overlay — which itself is the first shortcut we ship. A cheat sheet modal is one keypress and one component; it converts "hidden features" into "power user flex".
4. Don't override what the browser owns. Ctrl+F, Ctrl+L, number keys on tabs. We once watched a client's app hijack Cmd+1..4 for internal tabs and their support queue fill with browser-tab-switching complaints within a week.

The test setup that keeps it honest

Keyboard regressions sneak in through visual refactors, so they need mechanical enforcement. What works for us:

• Interaction tests through the keyboard only. Playwright's page.keyboard driving the critical flows end-to-end: "new invoice, add three rows, save, void" with zero mouse events. If a flow can't be completed that way, the test fails — which is the point.
• A tab-order assertion. On key screens, snapshot the sequence of focused elements across the first twenty Tabs. When someone adds a decorative button above the fold, the diff reviewer immediately sees the order change — and our CI budgets approach treats tab-order drift the same way it treats bundle-size drift: small, reviewable, enforced.
• One axe pass plus one human pass. Automated tooling catches missing roles and unlabelled controls. It will never notice that your date picker requires forty-one arrows to pick next Tuesday. The human pass — twenty minutes, one screen, keyboard only — catches the things that make people actually switch products. We fold it into the same audit process described in our accessibility audit article.

Where keyboard-first pays rent

The anecdote we tell clients: after the Northwind rebuild shipped with full keyboard support, the bookkeeping firm that beta-tested it cut its median invoice-processing time by a third (illustrative, but directionally what we measured). Nobody asked for "accessibility". They asked for speed, and the keyboard was where the speed was. Our dashboard design piece covers the visual half of that story; this was the interaction half.

Treat the keyboard as a primary input, build the few patterns properly once, and the rest of the interface inherits the quality. It's core to how our product engineering practice scopes dense tools — and it's one of the highest-leverage investments a product team can make.

Key takeaways

• Tab between regions, arrows within them. One stop per composite widget via roving tabindex turns keyboard traversal from a pilgrimage into six keystrokes.
• The modal contract — focus in, cycle within, Escape closes, focus returns — is testable, short, and broken in most codebases.
• Shortcuts live or die on discoverability: gate them from editable contexts, use chords, show them in the UI, never override the browser's own.
• Enforce keyboard flows in CI with keyboard-only end-to-end tests and tab-order snapshots, then run a human keyboard-only pass on each release.
• Sell keyboard-first internally as power-user speed. It is also, conveniently, accessibility — the two framings share one codebase.

FAQ

Should we use a library for focus management? For focus traps in modals, yes — focus-trap or your framework's headless primitives are battle-tested and homegrown traps almost always leak Shift+Tab or break inside iframes. For roving tabindex in lists and toolbars, the pattern is simple enough to own and you'll need the control anyway for virtualisation and type-ahead.

How do virtualised lists work with keyboard navigation? Keep the focused index in component state, completely decoupled from what's mounted. When focus enters the list, restore to the rendered row nearest that index; when arrows move focus, scroll the row into view first, then focus it. Never let the focused element unmount while it holds focus — that's the classic virtualisation bug.

What about screen readers — does keyboard-first cover them? It covers about half. Screen readers need correct roles, names and live regions on top of operable keyboard mechanics, and they're tested with actual screen readers, not assumptions. But every keyboard-first improvement — sane order, working modals, discoverable commands — makes the screen-reader experience better too.

Is tabindex="-1" on non-interactive elements ever okay? Yes, for managed focus: sending focus to a heading after a route change, or to an error summary after a failed submit. The rule of thumb: -1 means "focusable by script, not by Tab", and anything you focus by script should be worth the user's attention.