WCAG 3.2.1 — On Focus
Tab onto a field, the page navigates away. Focus a button, a modal opens. These "helpful" focus-triggered changes derail keyboard and screen-reader users who were just exploring the layout.
What this requires
When any user interface component receives focus, it must not initiate a change of context. A change of context includes opening a new window, navigating to a new page, moving focus to a different component, or substantially changing the content of the page. Focus moves should be passive — the page reacts to user activation, not to focus alone.
How AI coding tools fail this
When asked to "open the menu on focus" or "show the autocomplete as
soon as the field is focused", AI tools wire up onFocus handlers
that change the page state in ways the user didn't request. Tab
through a form, dropdowns open and close, focus jumps, the user
loses track of position.
The second pattern: redirects on focus. A "tap to start" field focuses on page load and immediately navigates to a deep link. Screen-reader users who landed on the page can't read anything before the redirect fires.
The third: modal dialogs that auto-open when their trigger receives focus. The user was tabbing past the trigger; the modal traps them.
Edge cases
- Showing related help text on focus is fine — it's information, not a context change.
- Highlighting the focused row in a table is fine.
- Opening a tooltip on focus is fine (and required by some patterns), as long as the page doesn't navigate or substantially change.
- Autocomplete suggestions appearing on focus are a grey area — arguably a content change. The safer pattern is to show them on the first keystroke.
- 3.2.1 vs 3.2.2: 3.2.1 covers focus; 3.2.2 covers input (changing a setting).
How Jeikin handles this
The scanner flags onFocus handlers that trigger navigation
(router.push, location.assign), modal opens, or form submissions.
The dashboard records each finding and tracks the move to a
deliberate-action trigger.