- Success Criterion 2.4.3
- Conformance level A
2.4.3 · Focus Order
Lesson overview · Focus Order
In plain language
Keyboard focus must move through the page in an order that makes sense.
Who it affects
Keyboard and screen-reader users who follow focus rather than the pointer.
How to check
Tab through each page and each dialog: focus should follow the visual/logical flow, enter dialogs when they open, and return to the trigger when they close.
Common misconception
Visual order and DOM order can look identical to a sighted developer and still diverge completely for a screen reader, especially once CSS positioning or grid layout gets involved.
Learn more
Scenarios in this lesson
- 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
- Hidden Navigation Items That Are Still Reachable by Tab
- Looping Carousel Clones Creating Duplicate Tab Stops
- Multi-Column Form With an Illogical Keyboard Tab Order
- Skip Link Injected at a Point That Breaks the Tab Order
- Focus Jumping to the Page Top on Every Route Change
- Toolbar With a Broken Roving Tabindex Pattern
- Sticky Element Receiving Focus at the Wrong Point in the Flow
- Background Page Still Tabbable Behind an Open Modal
- One Control Creating Two Separate Keyboard Tab Stops
- Disabled Controls Still Included in the Keyboard Tab Order
- Decorative Element Wrongly Given a Keyboard Tab Stop
- Focus Resetting to the Top After Loading More Content
- Failed Form Submission Sending Focus to the Wrong Field
- Activating a Control That Throws Keyboard Focus Elsewhere
- Escape Key Closing the Wrong Layer in a Nested Dialog