Keyboard Navigation

People who build screens build them with a hand on the mouse, and they check their work the same way. So nobody ever finds out how the screen behaves for someone who can't use a mouse, and it ships that way.

The group that can't use one is wider than it first looks. Some people can't aim at small targets because of tremor or reduced grip strength. Some don't look at the screen at all and listen to it instead. A screen reader is software that speaks what's on the screen, and the thing that moves it from one item to the next is the keyboard — for those users the keyboard is the mouse. A developer with a sore wrist who can't touch a trackpad for a week lands in the same place.

The gap usually shows up as a single sentence. The week after Pagedeck shipped new sharing settings, a customer wrote in: "Tab never gets me to the Share button." The button was sitting right there on screen, but it had been wired to respond only to a click, so for anyone working from the keyboard it didn't exist. That's the moment a team learns that being visible and being reachable are two different properties.

Keyboard navigation is the rule that closes the gap: anything the mouse can do, the keyboard can do too. WCAG, the international standard for web accessibility, carries the same requirement as a numbered criterion.

The browser keeps an ordered list of the elements on a page that accept interaction, and each press of Tab moves focus one step along that list. Exactly one element holds focus at a time, and that element is the one receiving key presses. Enter or Space activates it.

Four groups of keys carry almost all of the work.

1. Tab — moves to the next interactive element; Shift and Tab together move backward. Only elements that natively take interaction — links, buttons, inputs — join that order.
2. Enter and Space — activate whatever holds focus. Links open on Enter, buttons take either one, checkboxes toggle on Space.
3. Arrow keys — move within a single group. Radio button sets and open dropdown lists are chosen with arrows rather than Tab, so a list of forty options doesn't cost forty Tab presses to get past.
4. Escape — closes whatever is currently open and returns focus to where it came from.

Two extra behaviors sit on top of that. The first is trapping focus. Inside something like a modal — a window that blocks the screen behind it — focus has to stay within the window. Without the trap, a few Tab presses push focus onto a button hidden behind the modal, and the user is operating a control they can't see. When the window closes, focus goes back to the button that opened it.

The second is a skip link. If the header holds thirty menu items, reaching the main content costs thirty Tab presses, so pages put a hidden link to the content first and reveal it on the very first Tab.

Most of the ordering comes free from semantic markup, the practice of using the tag that matches what an element actually is. A real button element joins the tab order and responds to Enter with no extra work. A styled box shaped like a button needs both behaviors attached by hand, and one of them usually goes missing.

Three places account for most of the failures.

1. Hand-built components — dropdowns, tab bars, and date pickers assembled out of generic boxes because no standard tag produces that shape. They need arrow-key rules and ARIA, the attribute spec that tells assistive technology whether a control is currently open, selected, or disabled.
2. Overlays — modals, side panels, confirmation dialogs. Skip the move-and-restore handling for focus and a user who closes the dialog starts tabbing again from the very top of the document.
3. Tables and long lists — in a hundred-row table with three buttons per row, Tab alone takes three hundred presses to reach the last row. Arrow keys move between rows and Tab cycles only within the current row.

All three depend on the focus ring, the outline that shows which element currently holds focus. Designers often strip it because it looks untidy in a mockup, which leaves keyboard users pressing Enter without knowing where they are. The path is open and the signposts are gone.

A screen that fully works this way pays off outside accessibility too. Anyone who repeats the same task dozens of times a day is faster with their hands never leaving the keyboard.

"This dropdown won't open with Tab. Try it with your hand off the mouse."

The implementation is listening for mouse events only.

"The review flagged that you can't reach checkout from the keyboard."

An accessibility check found the break in the purchase flow, so it has to be fixed before release.

"The mockup has no focus state, so we end up deciding it during implementation."

When design doesn't specify it, each developer fills the gap differently and the screens drift apart.

At Pagedeck, Noa pushes the mouse aside during every feature review and walks the whole flow with Tab — opening the sharing dialog, changing a permission, closing it again, all from the keyboard. Last time, closing the dialog dropped focus back at the top of the document, and Theo added the handling that returns it to the button that opened it.

The most common mistake is reading this as a separate feature for a small group. Filing it under accessibility makes that easy to assume. But the people driving screens from a keyboard include power users moving quickly between form fields and anyone whose mouse has just died, not only assistive technology users. Treated as a separate feature, it's the first thing cut when a schedule slips — and reworking focus order after a screen is finished usually means rebuilding its structure.

The second mistake is thinking that reachable is the finish line. Since people test by pressing Tab, reachability is what they end up checking. But an order that disagrees with the visual layout is unusable even when everything is reachable. If a form reads top to bottom while Tab jumps first to the button at the bottom right and then climbs back up, someone who can't see the screen has no way to work out where they are. Reachable is the minimum; the order has to match the reading order before the screen is actually usable.