- Success Criterion 2.4.3
- Conformance level A
Failed Form Submission Sending Focus to the Wrong Field
2.4.3 — Focus Order
Scenario
Setting
A calendar app's event-creation form
What’s wrong
After a failed form submission, focus jumps to the wrong place — the last error instead of the first, or somewhere unrelated, so keyboard users fix errors out of order or hunt for them.
Example
.field-3 { order: 1; } .field-1 { order: 3; } /* tab order scrambled by CSS */Why it matters
Keyboard and screen-reader users who follow focus rather than the pointer.
How to test
Submit a form with multiple errors: check where focus lands — it should move to the first error (or an error summary), not the last error or somewhere unrelated.
How to fix
On failed submission, move focus to the first error (or an error summary linking to each field).
<!-- Reorder the actual DOM nodes to match the intended focus sequence -->Focus order should follow a sequence that preserves meaning, matching how the content is meant to be read.
Outcome
On a calendar app's event-creation form, this barrier is gone for keyboard and screen-reader users who follow focus rather than the pointer — they reach the same outcome without extra effort.
Who is affected
Keyboard and screen-reader users who follow focus rather than the pointer.
Learn more
- Understanding Understanding document (opens in a new tab)
Related scenarios
- Tab Order That Jumps Around the Page Illogically
- Dialog That Opens Far From the Button That Triggered It
- Visual Layout Order That Doesn’t Match the Keyboard Tab Order
- Modal That Opens Without Moving Keyboard Focus Into It
- Modal That Closes Without Returning Focus to Its Trigger
- Expanded Content That Never Receives Keyboard Focus