The keyboard grammar
27 keysEvery key the Authoring Practices bind, and every pattern that binds it.
The finding. Arrow Down, Arrow Up and Enter are each bound by thirteen patterns; Home and End by eleven. Space and Enter do not activate the same things, which is where the confusion comes from — the specification itself is inconsistent.
What is being counted
The Authoring Practices describe thirty interaction patterns — combobox, menu, tabs, tree view — and each one has a Keyboard Interaction section listing the keys it binds and what each does. This collection reads all thirty of those sections and turns them inside out: instead of what keys does a combobox use, it answers what does this key mean, across the whole vocabulary.
So a bar reading 13/30 means: of the thirty patterns in the specification, thirteen of them bind this key to something. It is a measure of how load-bearing a key is — not how often people press it, and not whether pressing it is a good idea.
Why this is a grammar. Nobody designed it. Twenty-seven keys acquired meanings one pattern at a time, over twenty years, and the result behaves like a natural language: mostly consistent, learnable, and with irregularities that have to be memorised because there is no rule behind them. The most-bound keys are the grammar's function words — Arrow Down, Arrow Up, Enter carry meaning almost everywhere, which is exactly why breaking one is so expensive.
The irregular verb: Enter and Space
Both are described as “activate”. They are not the same key, and the specification does not make them the same key.
This is where “I pressed Enter and nothing happened” comes from. It is not a browser bug and it is not a user error — it is an inconsistency in the source document, reproduced faithfully by everyone implementing it.
Tab through it
Every key above is a key you press once focus is already somewhere. The Authoring Practices do not describe the key that put it there, because Tab belongs to the document, not to any pattern. This is that key, on a specimen modelled on a real registration form — and the two numbers under it are counted off the DOM, live, not typed in.
The two numbers differ because of one rule. Three radio buttons are one tab stop, not three: Tab moves between groups and the arrow keys move inside one. That is Arrow Down and Arrow Up in the table above, doing the job Tab is not doing — and it is why a radio group built out of buttons feels wrong to anyone who navigates by keyboard, even when every button works.
Nothing is broken and nothing has moved. The specimen still has the same tab stops in the same order, and it is still telling this page exactly where you are. It has simply stopped telling you. Tab through it now, then put the ring back and see the path you took.
What the ring is, in the specification. 2.1.1 Keyboard A · 2.4.7 Focus Visible AA · 2.4.11 Focus Not Obscured (Minimum) AA · new in 2.2 · 2.4.13 Focus Appearance AAA · new in 2.2
Nobody designed the ring you just used. It is the browser's own, drawn by default on every focusable thing since focus existed, in the platform's own colour. That is the whole shape of this failure: the accessible behaviour is what you get for free, and losing it takes an instruction.
Removing the ring does not fail one of these. It fails the first as well: a control you cannot locate is a control you cannot operate, and 2.1.1 Keyboard is Level A. The commonest way this happens is not a decision — it is outline: none written once to tidy up a button, and inherited by everything.
Every key, and every pattern that binds it. Sorted by how widely bound. Open a row to see the patterns by name — 7 of the twenty-seven are bound by exactly one pattern, and those are the ones nobody can be expected to know.
Source. ARIA Authoring Practices, keyboard interaction sections · W3C Document Licence · retrieved 2026-07-31. This collection is derived.
The documents. APG keyboard interaction