Most teams treat keyboard navigation as something QA checks at the end of a project. Tab through it. See if anything breaks. File a ticket if it does.
What you end up with is a product that passes the check and still frustrates the people who need it most.
When keyboard navigation is tested instead of designed, you get tab orders that follow the DOM structure instead of the user’s workflow. You get modal dialogs that let focus escape when users need it contained. None of those things fail an automated check. They just make the experience frustrating for people who depend on it.
The users who rely on keyboard navigation are real. People with motor impairments. Power users who live in keyboard shortcuts. Anyone filling out a long form who doesn’t want to reach for a mouse every 30 seconds. These aren’t edge case users. They’re just users.
Here’s what designing for keyboard navigation actually looks like:
Focus order should be mapped during wireframing, not inferred from the DOM after handoff. Annotate it the same way you’d annotate spacing or interaction states; mark the entry point, trace the primary task path, and flag anywhere the flow might break. Tab order should follow the task, not the layout. A checkout form should move field by field in the order a user fills it out, not bounce around based on where elements sit in the grid. For dialogs, specify where focus enters when the dialog opens (usually the first actionable element or the dialog heading) and where it returns when it closes, back to whatever triggered it, not reset to the top of the page.
Focus styles are an often-skipped design decision in this whole space. Personally, I think that is a good thing. Keeping the default browser focus style falls in line with Jakob Nielsen’s fourth heuristic: Consistency and standards. Users spend most of their time on sites and applications other than yours. They are used to system defaults, and it is easier to spot the focus style if they already know what they are looking for. There is, however, an instance where you should consider your own style for the focus indicator: when the page background makes it so the default focus indicator does not have sufficient contrast to be easily seen. WCAG requires 3:1 against the adjacent background (including the control’s background if the outline touches it), but in practice you want higher than that. You want a visible offset so the outline isn’t swallowed by the element’s own border, and enough weight that it registers at a glance.
None of that is hard. It’s just intentional.
The difference between testing keyboard navigation and designing for it is the same as the difference between checking whether a door opens and thinking about who needs to walk through it.