What Does a Keyboard User Experience on Your Site Right Now?

Press Tab on your own homepage before you read any further. One press, on a freshly loaded page, with the mouse untouched. Most sites answer badly: nothing visible moves, or something moves that you cannot see, or focus lands somewhere inside a cookie banner and refuses to leave.

That one keystroke tells you more about keyboard accessibility than an automated scan will. Scanners are good at contrast ratios, missing labels and duplicate ids. They are close to useless on the three questions that decide whether a person can actually use the thing: can I see where I am, can I get where I am going, and can I get out of what I just opened.

This is not a minority concern parked behind a compliance checkbox. Keyboard operation is how switch users work, how most screen-reader users work, how people with tremor or repetitive strain injuries work, how anyone with a dead trackpad works, and how a fair number of fast typists work by preference. Fix the keyboard path and you have fixed something for several groups at once, which is rare enough to be worth the afternoon.

What follows is the pass we run on every build, in the order we run it, plus a fifteen-minute version you can run today on a site you did not design.

The first ten seconds tell you most of it

Three things happen at the start of a keyboard pass, and each one is a verdict on its own.

The first Tab press should reveal a skip link. If nothing appears, every keyboard user travels through your entire header on every page they visit, and if that header carries a mega menu the journey to the first paragraph is long enough to be insulting. A skip link is roughly four lines of HTML and CSS. It is the highest-value thing on this page and almost nobody has one that works.

The second question is where focus went, assuming it went anywhere. Browsers begin at the top of the document, which is fine, unless your document begins with a banner rendered last in the source and positioned first on the screen. Then the visible sequence and the actual sequence disagree, and the person pressing Tab has no way to predict what comes next.

The third is whether you can see any of this happening. If the answer is no, stop testing and fix that first. Everything else in this article is undiagnosable while the indicator is missing, because you are guessing at where focus sits rather than watching it move.

What keyboard accessibility actually requires

The standard is narrower and more useful than people assume. WCAG asks that all functionality is operable through a keyboard interface without requiring particular timings for individual keystrokes, and that focus can always be moved away from a component using the keyboard alone. Two supporting requirements do most of the day-to-day work: focus has to be visible, and the order focus moves in has to preserve meaning and operability.

WCAG 2.2 added a requirement that the focused element is not entirely hidden by content the author added, which is the sticky-header problem finally written down as a rule. If your header covers the field a user just tabbed into, that is now a failure rather than an irritation. It is also the easiest regression to introduce, because it arrives with a design change nobody thought was functional. Our own accessibility commitment names the standard we hold work to, which is the only way it stays checkable.

Notice what the standard does not demand. It does not require you to rebuild drag-and-drop as an arrow-key ballet for its own sake. It requires that whatever the drag accomplishes can also be accomplished from the keyboard by some route. The obligation attaches to the outcome, not the gesture, and teams that miss this distinction build elaborate keyboard versions of interactions nobody needed while leaving the checkout unreachable.

The fifteen-minute test

Anyone can run this. No tooling, no extension, no training. Do it in order and write down what you find as you go.

1. Load the homepage and press Tab once. A skip link should appear and, when activated, should move focus into the main content rather than merely scrolling the page there.
2. Tab through the header to the end. Watch whether the visible order matches the order focus takes, and count the presses. If it is more than a dozen, the skip link is not optional.
3. Open the main menu without hovering. Every submenu must open on focus or on Enter, and close on Escape. Hover-only menus are invisible to the keyboard entirely.
4. Open every overlay the site has. Search, cookie notice, chat launcher, image viewer, any modal. For each one: does focus go in, stay in, and come back out where it started?
5. Complete the main form, keyboard only. Trigger a validation error deliberately. Was the error connected to the field it belongs to, or was it only coloured red and placed nearby?
6. Reach the footer on your longest page. Lazily loaded lists and infinite scroll routinely make the footer unreachable, which quietly removes the legal links from the keyboard path.
7. Scroll halfway down and start again. Sticky headers and floating bars hide the focused element in exactly this state, and never in the state you tested from the top.

Record findings as specific failures with the page and the control named, not as impressions. A list of eleven concrete defects gets fixed in a sprint. A general sense that the site is awkward with a keyboard gets discussed in three meetings and survives them all. It is the same distinction that separates research that could have changed the plan from research that was performed at it.

Focus you can actually see

The most common single defect we find is a focus indicator that was removed deliberately, years ago, usually because somebody disliked the browser ring on one particular button and applied the fix globally. The button looked better. The site became untestable.

The line to search for

Search your stylesheets for outline: none and outline: 0. Every match either sits next to a replacement indicator on the same element, or it is a bug. There is no third category, and reset stylesheets copied in from elsewhere are the usual source. Check the CSS your component library ships too, because that one is invisible in your own repository.

What a usable indicator needs

• Visibility on every background it lands on. A dark ring works until focus reaches the dark band in the footer. Test the indicator on the page sections, not on a blank canvas.
• More than a colour change. A tint swap on its own is easy to miss and unreliable for people who do not distinguish those colours. Add a ring, a thickness change or an offset.
• Room to breathe. An indicator drawn inside a busy control disappears into it. A small outline offset separates the ring from the element it belongs to.
• Presence on custom controls. Elements built from divs inherit nothing. If you invented the control, you own its focus state as much as you own its hover state.
• Survival of overflow. A ring drawn outside an element gets clipped by a scroll container with hidden overflow, so the control looks unfocused while it holds focus.

The modern compromise is focus-visible: keyboard users get the indicator, mouse users do not get one on click. That is the behaviour designers actually wanted when they reached for outline: none, and it has been supported widely enough for long enough that removing indicators is no longer a defensible trade.

Order, and why it drifts

Focus order follows the document, not the design. Obvious, until a layout is rearranged with grid placement or flex ordering and the visual sequence quietly stops matching the source. Then focus jumps from the top of the page to the bottom of a card, back up to a heading, and out to a sidebar. A sighted keyboard user loses the thread within four presses.

The tabindex trap

Tabindex has three useful shapes and one harmful one. A value of 0 puts a custom element into the natural order where it sits in the document. A value of -1 makes an element focusable by script but not by Tab, which is how you move focus to a heading inside a newly opened dialog. Any positive number drags the element to the front of the entire page order. Once one positive value exists, somebody adds a second, then a third, and the order becomes a spreadsheet that nobody maintains and everybody breaks.

Reordered layouts and breakpoints

This bites hardest where source order was chosen for one breakpoint and visually rearranged for another, so the keyboard path is sane on a phone and scrambled on a laptop, or the reverse. It is one more reason that mobile first is not a layout decision: the source order it forces on you is also your focus order at every width, and it is much cheaper to get right once in the markup than to patch per breakpoint forever.

Traps, and what Escape is for

A trap is any place focus can enter and cannot leave using the keyboard alone. The old-fashioned version is an embedded player or third-party iframe that swallows keystrokes. The modern version is a modal built as a div that appears over the page while focus is still sitting on the button behind it, so Tab wanders through the content underneath while the dialog stares at nothing.

A dialog owes four things, and dropping any one of them breaks it: move focus in when it opens, hold focus inside while it is open, close on Escape, and return focus to the control that opened it. The fourth is the one that gets forgotten. Without it, closing a dialog strands the user at the top of the document with no memory of where they were, which is worse than the trap because it looks like it worked.

Where a native element exists, use it. A disclosure built from the details and summary elements is keyboard-operable with no script at all, so it cannot regress when someone refactors a bundle or a hydration step fails. We reach for native elements not out of purism but because they are the components that keep working on the day the JavaScript does not arrive.

Every control you can reach, operate and leave without a mouse is a control you have also repaired for switch, voice and screen-reader users.

The components that usually fail

After enough passes the failures start repeating. These are the components we check first, because they are wrong more often than they are right.

The floating widget earns its own paragraph, because it is usually the last thing added to a site and the first thing to break. A widget offering contact, information and conversion actions, of the kind Flidu packages, is still a launcher button and a panel: Tab has to reach the launcher, Escape has to close the panel, and focus has to come back afterwards. Our parent company set out the full pattern in an accessible chat widget, and the announcement problem underneath it is covered in where a floating chat widget fails a screen reader.

One component nobody ever tests: the empty state. When a filtered list returns nothing, the region collapses, the focus path through it changes, and the control that would let somebody recover is frequently the one control that never received a focus style. That is part of why empty states are the most neglected screen in most products: they are designed last and tested never.

What we would fix first

If the pass produced a list, work it in this order, which is not severity order. It is the order in which each fix makes the next one possible. Restore focus indicators, because you cannot debug an order problem you cannot see. Then remove traps, because a trap makes everything after it unreachable. Then add the skip link. Then correct source order. Then the individual components, worst first.

The honest limitation: a keyboard pass is not an accessibility audit. It says nothing about colour contrast, alternative text, label associations, reading order announced by a screen reader, or whether your writing can be understood. It is one axis of several. What makes it worth running first is that it is quick, needs no tooling, and finds precisely the class of defect that automated checkers systematically miss.

There is also a case where the advice bends. In a genuine canvas application, a map, or a drawing tool, some interactions have no sensible one-to-one keyboard equivalent, and forcing one produces a path so long that nobody would use it. The obligation there is a deliberately designed alternative route to the same outcome, documented and discoverable, rather than a Tab order that technically touches every pixel and helps nobody.

Everything we design and build takes this pass twice: once when the components are designed and once on the assembled pages, because components that behave alone frequently misbehave together. If you would rather not run it yourself, send us a URL and we will walk it, or fold the same review into product design work already under way.