Keyboard navigation, explained without the jargon

Every audit we run turns up some version of this. Here is keyboard navigation without the vocabulary that usually surrounds it.

The cost of retrofitting accessibility is several times the cost of building it in. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

Everything clickable must be reachable by tab. In practice this is a scheduling problem more than a technical one. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Getting it slightly wrong is survivable. Ignoring it entirely is not.

Focus order should follow visual order. The cost of getting this wrong is rarely visible on the day it happens. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Where to go from here

Custom widgets are where keyboard support usually breaks. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

What this looks like day to day

Accessibility work almost always improves the experience for people who have no impairment at all. Three things worth confirming about keyboard navigation before you move on:

• Someone can say what the current setup is without going to look
• Everything clickable must be reachable by tab — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.