Keyboard navigation: what it actually requires from a designer

Most designers think of keyboard navigation as an engineering concern. You design the interface, and somewhere in the handoff the developer wires up Tab support. This understanding is wrong in a specific way that causes real harm: the decisions that most commonly break keyboard navigation are design decisions, made in the design file before any code exists.

Order is a design decision. Which elements are interactive is a design decision. What happens when an overlay opens is a design decision. Where focus goes when an action completes is a design decision. When designers aren't making these calls explicitly, engineers infer them from visual layout, and the same failures appear in every codebase.

Why DOM order is a design artifact

Tab order in a web interface follows the DOM by default. The DOM order follows the design file unless an engineer manually overrides it. So the reading and navigation order of your interface is a direct consequence of how you stack layers and arrange elements in your design tool.

The failure case looks like this: a card component has a title, description, and "View details" link arranged visually so the link sits below the title. In the design file, the link layer is above the title layer because you added it last. The engineer builds it in layer order. Now the Tab sequence hits the link before the title, which is backwards to what a visual scan would expect. The keyboard user navigates out of sequence with no indication that anything is wrong.

This happens constantly. The fix is for designers to annotate Tab order on any layout where the visual arrangement doesn't match a clean left-to-right, top-to-bottom reading. That annotation belongs in the spec, not as a comment at handoff.

Interactive elements have to be specifiable

When you design a component with a click target, you're implicitly specifying an interactive element. The problem is that designers often add click behavior to elements that aren't inherently interactive: a div, a styled container, an icon without a label. These render beautifully and are completely unreachable by keyboard unless the engineer knows to add tabindex and keyboard event handling.

The better habit is to design from the semantic model outward. Before you place a clickable thing, ask what HTML element it should be: a button, a link, a checkbox? The design should reflect that decision. A "button" in your design file that's really a styled div is a gap between intent and implementation that will close badly.

Dropdowns, comboboxes, and date pickers deserve special attention. These components have established interaction patterns: which keys open them, which close them, how arrow keys move through options. If you're designing a custom version of any of these without referencing the ARIA Authoring Practices Guide pattern for that component, you're probably specifying behavior that conflicts with what keyboard users expect.

What you have to spec for overlays

Modals, drawers, and tooltips are where keyboard accessibility most visibly breaks. The failure modes are consistent enough that I've seen the same ones on every large codebase I've audited.

When an overlay opens, focus needs to move inside it. Not to the top of the page, not to the element below the trigger, but to the overlay itself. Either the first interactive element or the container.

While the overlay is open: Tab should be trapped inside it. The user can't reach content behind the overlay with a mouse, so they shouldn't be able to reach it with Tab either. Reaching behind an overlay is disorienting; you can't see where focus has gone.

When the overlay closes: focus returns to the element that opened it. Not the top of the page, not wherever the browser decides. The trigger. Every time.

Designers almost never specify this. The behavior is invisible in the design file because overlays in design tools are static. But annotating these three states for every overlay pattern in your product is a small amount of work that prevents a predictable class of bug. Open, active, close.

Visible focus states are a design deliverable

The default browser focus ring is functional. It's also inconsistent across browsers, sometimes invisible against your background color, and often overridden by the team's global CSS reset. The fix for this has to come from design.

A custom focus style isn't just a nicety. It's a first-class design decision, like hover states. Every interactive component should have a designed focus state that's visible against all backgrounds it can appear on. Two pixels of solid outline with two pixels of offset covers most cases. The color needs to meet WCAG contrast thresholds against both the element's background and the page background behind the offset gap.

Skipping focus states because "we'll handle it in CSS" produces the same outcome as skipping hover states and saying "we'll handle it in CSS." You might. You might not. The behavior belongs in the design specification.

The actual scope of the work

Keyboard support isn't a feature. It's a mode of use that either works or doesn't for every feature you ship. The scope of keyboard design isn't a separate section in the spec. It's a property of every interactive element.

That sounds daunting until you realize how much of it is mechanical. Tab order, focus states, focus management on overlays: these are patterns. Once your team has documented the pattern for dialogs, you apply it consistently. Once your token system includes a focus style, every component inherits it. The first few components require thought. After that it's mostly execution.

The teams where keyboard accessibility consistently breaks are the ones that treat it as a post-design concern. The teams that get it right have designers who, when they put an interactive element in a layout, think through what hitting Tab will feel like.