Spatial navigation

A keyboard walks a page in one dimension: Tab goes forward through a sequence, Shift and Tab go back. A remote control has no such key. It has a ring of four directions and a select button, and so the only question it can ask is “what is the nearest thing that way?” Spatial navigation is the answer: focus moves to the closest candidate in the direction pressed, measured in geometry rather than in source order.

The two models disagree constantly, and that is the thing to internalise. A grid whose source order runs across the rows still walks correctly with Tab, but pressing Down from the third cell is a geometry problem whose answer may be several positions away in the DOM. Put a tall card, a missing cell, or a floating panel into the layout and the divergence gets worse: direction hops over the hole, while the sequence walks patiently into it. This is why a ten-foot UI cannot be tested by tabbing through it. The navigation model that ships to the television is not the one your keyboard is using.

Browsers do part of this already. Arrow keys scroll, and CSS Spatial Navigation Level 1 specifies directional focus movement with spatial-navigation-action and nav-up-style overrides, but the feature is unimplemented outside experiments, so in practice a TV interface ships its own focus engine. If you are writing one, the two rules that matter most are alignment beats proximity (a candidate overlapping the current element’s own extent should win over a nearer diagonal one) and the move must be reversible, because a Right that cannot be undone by a Left makes a remote feel broken within seconds.

Inside a single widget the answer is usually not a focus engine at all. A roving tabindex is the established way arrow keys move around one composite control, and it keeps the widget as a single stop in the page’s own focus order. Spatial navigation is the model for a whole interface whose only input is a direction pad, not a technique to sprinkle over a form.