Keyboard focus is essential for a wide range of users, especially:
- people with no vision who use screen readers
- people with limited movement who rely on the keyboard or keyboard equivalents
But how do browsers know where to send focus? Are there specific rules they need to follow?
The answer is yes.
Keyboard focus is not guesswork. It is defined across several parts of the HTML and DOM specifications, each describing a different aspect of how focus should behave.
This article highlights six key documents that determine keyboard focus behaviour.
Who should care about these specifications?
Understanding where focus rules live is valuable for anyone who builds or maintains interactive user interfaces, including:
1. Front-end developers
Especially those working with complex, non-native components such as:
- custom dialogs
- dropdowns
- menus
- accordions
- popovers
- Shadow DOM components
2. Accessibility professionals
Knowing the true source of focus behaviour helps you:
- diagnose “focus bugs” more accurately
- explain native keyboard behaviour to teams
3. Design system and component library teams
Design systems fail when focus becomes unpredictable. These teams must ensure:
- consistent focus behaviour across all components
- correct tab order
- clean focus indicators
4. UX designers and interaction specialists
Understanding the native rules leads to simpler, more robust designs. Focus rules shape:
- keyboard interaction models
- accessible navigation patterns
5. QA testers and auditors
Knowing how focus should behave helps testers:
- identify regressions
- evaluate AT compatibility
- recognise keyboard-based bugs
Why should you care?
Together, these specifications explain the foundations of keyboard interactions:
- how browsers calculate the tab order
- how native elements behave with or without
tabindex - how focus moves across Shadow DOM boundaries
- why some elements cannot receive focus
- what happens inside the browser when focus changes
- how popovers, dialogs, and other layered UIs should manage focus
- where accessibility APIs fit into the process
Let’s look at the specs!
1. HTML Standard — “Sequential focus navigation”
Section: 6.6.5 Sequential focus navigation
This section defines how the browser decides which element receives focus when the user presses Tab or Shift+Tab. It is the closest thing to the “focus navigation algorithm” most developers imagine.
It defines:
- how browsers collect the list of sequentially focusable elements
- how the tab order is constructed
- what happens when the user moves forward or backward through that order
2. HTML Standard — “The focusing steps”
Section: Focus steps
These are the actual steps a browser runs when setting focus.
It defines:
- blurring the previously focused element
- firing
focusinandfocusevents - adjusting text selection when needed
- scrolling the focused element into view
- retargeting focus through Shadow DOM
- exposing the focus change to accessibility APIs
This is the core “what happens during focus” algorithm.
3. HTML Standard — “Can be focused” steps
Section: Can be focused
This algorithm determines whether an element is allowed to receive focus. It answers the common question: “Why isn’t this element getting focus?”
It checks:
- whether the element is natively focusable
- whether
tabindexchanges its focusability - whether it is disabled
- whether it is hidden (
display:none,visibility:hidden,inert) - whether it is editable or contains a browsing context
- Shadow DOM rules that affect focusability
4. HTML Standard — “Tabindex order”
Section: The tabindex attribute
This section defines how tabindex values influence the tab order.
A key detail is that tabindex values greater than 0 create a custom tab order, which must be sorted numerically before any tabindex="0" or native focusable elements. This often leads to unexpected or broken focus patterns on large UIs.
It defines:
- how elements with
tabindex > 0are sorted - how
tabindex="0"fits into DOM order - how native focusable elements are integrated
- why relying on
tabindex > 0is discouraged
5. HTML Standard — “Popover focusing steps”
Section: Popover focus
This algorithm handles the focus behaviour associated with popovers and popover-like UI. Although the Popover API is new, its focus rules affect many common interaction patterns.
It affects:
- how focus is trapped inside a popover
- what happens to focus when the popover closes
- how focus is restored to the triggering element
- how nested or overlapping popovers behave
This matters even if you aren’t using the Popover API directly, because many UI libraries mirror this behaviour.
6. Shadow DOM–specific focus rules
Sections: Shadow tree and Retargeting
The DOM Standard doesn’t define its own “focus algorithm,” but it defines the rules that shape how focus behaves inside custom elements. These rules explain why focus inside custom elements can feel different to focus in the light DOM.
These documents define:
- how the composed tree is constructed
- how focus and blur retarget across Shadow DOM boundaries
- how the shadow host and internal elements appear to event listeners
- how
delegatesFocuschanges click-based focus behaviour
Conclusion
These six documents form an overall “rulebook” that browsers follow when managing keyboard focus.
Understanding these rules is important when diagnosing issues, designing reliable interactions, and building components that work predictably for everyone who relies on the keyboard.