WCAG 3.2.1 On Focus

What it asks

When people move through a page with the Tab key, each stop is a chance to find out what a control is before doing anything with it. This rule says that merely arriving on a control must not change the context. WCAG means something specific by that: opening a new window or tab, moving focus to a different control, going to a new page, or rearranging the content so much that the person loses their place.

A control can still react to focus. Showing a tooltip, highlighting the control, or opening a drop-down list to show its options is fine, because the person is still where they were. What is not fine is a search field that submits the moment it is focused, a select that loads a page as soon as the keyboard reaches it, or a field that opens a dialog on focus so that the person never reaches the fields after it.

The failures are rare, but when they are present they can make a page impossible to use with a keyboard at all. A person tabbing down a form cannot pass a field that throws them somewhere else every time they land on it. It is Level A, and it applies to every focusable element: links, buttons, fields and custom widgets alike.

Its official name is success criterion 3.2.1 On Focus, at Level A. It was added in WCAG 2.2, under guideline 3.2 Predictable and the principle Understandable. The W3C’s normative text says, in part:

“When any user interface component receives focus, it does not initiate a change of context.”

From WCAG 2.2, W3C. Full explanation: Understanding 3.2.1 On Focus.

Who it helps

People who use a keyboard, a switch or voice control to move through a page, who reach every control by passing over the ones before it. If passing over a control fires it, they cannot get past it.

Screen reader users, who move focus to a control in order to hear what it is. People with low vision using magnification, who may not see that the page changed. And people with cognitive disabilities, who are disoriented by changes they did not ask for.

What passes and what fails

These pass

• A link that shows an underline and a focus ring when focused, and goes nowhere until activated.
• A text field that shows a tooltip with format advice when it receives focus.
• A select that opens its list on focus but changes nothing until an option is chosen.
• A dialog that is already open and keeps focus inside itself while it is open.

These fail

• A select that navigates to a new page as soon as it receives focus.
• A search field that submits the form when focused.
• A field that opens a dialog on focus, so that tabbing through the form always ends up in the dialog.
• A field that moves focus to a different field the moment it receives it, so that the first field can never be reached from the keyboard.

How to test it by hand

1. Open the page and press Tab from the top, pausing at every control. Then press Shift and Tab to come back up.
2. At each stop, do nothing but look. Note any new page, new window, dialog, jump of focus or large change to the content that happens on arrival.
3. Repeat inside menus, expanded sections and dialogs, where custom controls are more common.
4. Repeat with a screen reader, which moves focus in its own way and can trigger handlers a plain Tab does not.
5. Write down every control that changed the context on focus alone.

What automated testing can decide

What a machine can decide

This is one of the criteria automated testing can observe rather than guess at. A tool can reach each control with the keyboard and note whether arriving on it opened a new page or window, moved focus elsewhere or changed the content in a large way. Each of those is an observation, not an opinion, and the control that caused it is known.

What it cannot

Automated testing only covers the controls it reaches. A control inside a menu that was never opened, or in a state the test never reached, is untested. Deciding whether a smaller change counts as losing one’s place can still take a person.

How Dreven handles it

Dreven finds the controls on your pages that changed something when they received focus and shows you what changed, with a picture of the page before and after.

A reviewer decides each result, and the report says which pages, controls and states were covered, so a pass is never read as wider than what was tested.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.2.2 On Input (Level A). The same rule for changing a control’s value rather than reaching it.
• 2.1.1 Keyboard (Level A). Everything must be usable from a keyboard, which a context change on focus defeats.
• 2.4.3 Focus Order (Level A). Focus must move in an order that makes sense, and a control that throws focus elsewhere breaks that order.
• 2.1.2 No Keyboard Trap (Level A). Focus must never get stuck, and a control that keeps grabbing it is a trap of its own.

Questions people ask

All WCAG 2.2 criteria, in plain words