- 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
Open an online spreadsheet's toolbar and this is what you'll see: as soon as an element receives keyboard focus, a script throws focus away (blur) — keyboard users can never actually reach or use it.
Why it matters
Keyboard and screen-reader users, and people who are easily disoriented by surprise UI changes. On an online spreadsheet's toolbar specifically, they can't predict where to find the same feature.
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.
Outcome
Fixed, a visitor to an online spreadsheet's toolbar can find the same feature in the same place.
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