- Success Criterion 3.2.1
- Conformance level A
- W3C reference F55
Element That Loses Focus the Instant It’s Reached
3.2.1 — On Focus
Scenario
Setting
An online spreadsheet's toolbar
What’s wrong
As soon as an element receives keyboard focus, a script throws focus away (blur) — keyboard users can never actually reach or use it.
Example
<select onfocus="submitForm()">Why it matters
Keyboard and screen-reader users, and people who are easily disoriented by surprise UI changes.
How to test
Tab to an element and check if it loses focus immediately: unwanted focus-triggered changes can't even register if a blur() fires right away — check this first.
How to fix
Never call blur() on focus — let elements keep focus until the user moves it.
<select onchange="updatePreview()"></select><button onclick="submitForm()">Apply</button>Simply moving focus into a control must never trigger a context change like submission or navigation.
Outcome
On an online spreadsheet's toolbar, this barrier is gone for keyboard and screen-reader users — they get the same result as anyone else here.
Who is affected
Keyboard and screen-reader users, and people who are easily disoriented by surprise UI changes.
Learn more
- Understanding Understanding document (opens in a new tab)
- Technique Related technique (opens in a new tab)
Related scenarios
- Tabbing Into a Field That Opens a Modal Automatically
- Tabbing to a Menu Item That Auto-Navigates to Its Page
- Selecting an Option That Submits the Form Automatically
- Keyboard Focus Triggering an Unexpected Scroll Jump
- Tabbing Into a Field That Opens a Chat Widget
- Autofocus Chain That Jumps Focus From One Field to Another