WCAG 2.1 · Level A · Operable
WCAG 2.4.3 — Focus Order, explained with examples
Components must receive focus in an order that preserves meaning and operability — usually matching the visual reading order. When focus jumps backward in the page, drops to the bottom, or skips important controls, keyboard users get lost. The most common offender is a modal that, when closed, sends focus to the top of the page instead of back to the trigger.
- Number
- 2.4.3
- Level
- A
- Principle
- Operable
- Guideline
- 2.4 Navigable
Why this criterion exists
When focus jumps backward in the page, drops to the bottom, or skips important controls, keyboard users get lost. The most common offender is a modal that, when closed, sends focus to the top of the page instead of back to the trigger.
If you only remember one thing: components must receive focus in an order that preserves meaning and operability — usually matching the visual reading order. Everything else on this page is detail.
Who feels it when this fails
Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Focus Order affects:
Keyboard users
Screen reader users
How sites typically fail it
These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.
Closing a modal does not return focus to the trigger
Custom positionAbsolute/fixed components break visual ↔ DOM order
tabindex > 0 forcing artificial order
How to test for it
Tab through the page; sequence should make sense.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
Always remember the trigger and restore focus to it when the modal closes. This single rule eliminates 90% of focus order bugs.
The problem
closeModal() { modal.hidden = true; }The fix
let lastFocused = null;
openModal(trigger) {
lastFocused = trigger;
modal.hidden = false;
modal.querySelector('button').focus();
}
closeModal() {
modal.hidden = true;
lastFocused?.focus();
}Always remember the trigger and restore focus to it when the modal closes. This single rule eliminates 90% of focus order bugs.
Frequently asked questions
Why does focus order matter so much in single-page apps?
In multi-page sites, the browser naturally places focus at the top of a new page after navigation. In SPAs, the DOM mutates in place and focus stays wherever it was — often on a now-hidden or removed element. Without explicit focus management, screen-reader users land in an invisible element or the document body, with no indication that the page has changed. Every route transition needs a focus-restore strategy.
Should I avoid positive tabindex values to fix focus order?
Avoid tabindex values greater than 0 whenever possible. A tabindex of 1 or higher pulls the element to the front of the Tab sequence, which usually creates a surprising flow where the user jumps away from their current position in the DOM. Fix focus order by reordering the DOM to match the visual layout instead of using tabindex as a workaround.
What is the relationship between 2.4.3 and aria-modal?
aria-modal="true" on a dialog tells assistive technologies to treat only the dialog's content as available. Without it, some screen readers let users roam the entire page while the modal is visually open. Combined with correct focus management (move into modal on open, restore on close), aria-modal ensures the AT experience matches what sighted keyboard users see.
Other Operable criteria
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.