Focus is the one place on a page that is currently taking keyboard input. Type, and the characters go there. Press Enter or Space, and whatever is focused is what responds. Only one thing has it at a time, which is why moving focus is how anybody driving the page without a mouse gets from one control to the next. Two things about it are worth having straight early. The rule underneath is about functionality being operable through a keyboard, not about Tab reaching every element. A well-built menu that you enter with Tab and then move through with arrow keys is the correct pattern, not a gap. And a screen reader has its own reading cursor that moves independently of focus. Where the screen reader is and where focus is are two different questions. They only sometimes have the same answer.
In practice
Buttons, form fields and links carrying an href take focus by default. A div does not, unless it happens to be editable, so a control built out of one is unreachable until somebody adds tabindex to it, and adding tabindex only makes it reachable. Enter and Space still do nothing until somebody writes the key handling as well, which is the half that gets forgotten. Focusable is not operable.
The word keyboard in all of this is doing more work than it looks. What the standard asks for is operability through a keyboard interface, which is the software channel a program uses to receive keystrokes, and plenty of things feed that channel without anybody touching a keyboard. Speech-to-text software, on-screen keyboards and switch devices all arrive that way. That is why keyboard rules serve people who never use a keyboard. It is also why driving the mouse pointer from the numeric keypad does not count, because that goes through the pointer channel instead.
Where focus goes, whether you can see it, what order it moves in and whether you can get back out are four separate requirements with four separate tests. Together they decide whether the site works without a mouse, and they fail independently. A page can have a perfect tab order and no visible indicator, or a beautiful indicator that lands inside a dialog with no way out.
Why it matters
Focus is the load-bearing idea in keyboard accessibility, and it is also the one most often broken by accident rather than by omission. Nobody sets out to strand a keyboard user. They remove an outline because it clashed, or reorder a layout in CSS and leave the source order behind, or open a dialog without moving focus into it. Each of those is a small decision with the same result. If you only ever check one thing on your own site, check where focus is after every click that opens or closes something.
Two things one word means
The element that will receive the next keystroke, and the visible mark showing which element that is. The first is a browser state. The second is something you can style away in one line of CSS. Lose the first and nothing works. Lose the second and everything works, invisibly, for somebody who now has to guess.
Where this shows up on the site
Related terms
- Focus indicatorA focus indicator is whatever pixels change to show that a control is focused.
- Focus orderFocus order is the sequence focus travels in as you press Tab, and by default it follows the order elements appear in the code rather than the order they appear on screen.
- Focus trapA focus trap is somewhere on a page that keyboard focus can get into and not out of.
- Keyboard accessibilityKeyboard accessibility means every piece of functionality on the page can be operated through a keyboard interface.
- TabindexTabindex is an HTML attribute that decides whether an element can take keyboard focus and where it sits in the tab order.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.