Focus management is the practice of deliberately controlling where keyboard focus is placed as a web interface changes, so that keyboard and screen reader users always know where they are and can continue without searching. In web accessibility, it covers the visible focus indicator, a logical focus order, and moving focus programmatically when dialogs open, content updates or views change.
Browsers manage focus well for static documents: the Tab key follows the source order of interactive elements. Problems start when scripts add, remove or hide content. If the focused element disappears or new content appears elsewhere, focus can fall back to the top of the page, and the user loses context. Good focus management restores that context explicitly.
How keyboard focus works in the browser
At any moment, exactly one element in a document holds focus and receives keyboard input; scripts can read it through document.activeElement. Native controls such as links, buttons and form fields are focusable by default and appear in the sequential focus order that Tab and Shift+Tab traverse.
The tabindex attribute changes this behavior, and its values are often misunderstood. The table summarizes their effect.
| Value | In Tab order | Focusable by script | Typical use |
|---|---|---|---|
| Not set on native control | Yes | Yes | Links, buttons, inputs |
| tabindex=”0″ | Yes, in source order | Yes | Custom widgets built from generic elements |
| tabindex=”-1″ | No | Yes | Headings or containers that receive focus after a change |
| Positive value | Yes, before everything else | Yes | Avoid, it breaks the natural order |
The inert attribute removes a whole subtree from focus and from the accessibility tree, which is the modern way to block background content while a modal is open.
Requirements in WCAG
Focus management is not a single success criterion but is required by several WCAG criteria together. Meeting them is part of conformance at levels A and AA, which most accessibility laws and procurement rules reference.
| Criterion | Level | What it requires |
|---|---|---|
| 2.1.1 Keyboard | A | All functionality is operable with a keyboard |
| 2.1.2 No keyboard trap | A | Focus can always move away from a component |
| 2.4.3 Focus order | A | Focus order preserves meaning and operability |
| 2.4.7 Focus visible | AA | The focused element has a visible indicator |
| 2.4.11 Focus not obscured (minimum) | AA | Sticky headers or overlays do not hide the focused element entirely |
| 3.2.1 On focus | A | Receiving focus does not trigger an unexpected change of context |
WCAG 2.2 also adds 2.4.13 Focus appearance at level AAA, which sets a minimum area and a contrast ratio of at least 3:1 between focused and unfocused states. Many design systems adopt it as a target even when only AA is required.
Common focus management patterns
Most interactive components follow established patterns described in the ARIA Authoring Practices. Each pattern answers two questions: where focus goes when the component appears, and where it returns when the component closes.
| Situation | Focus on open or change | Focus on close |
|---|---|---|
| Modal dialog | First meaningful control or the dialog title | Back to the element that opened it |
| Route change in an SPA | Main heading of the new view | Not applicable |
| Deleted list item | Next item, or previous if it was last | Not applicable |
| Inline form error after submit | Error summary or first invalid field | Not applicable |
| Disclosure or menu | First item for menus, stays on toggle for disclosures | Back to the toggle button |
Composite widgets such as tabs, listboxes and grids use a roving tabindex or aria-activedescendant. Only one element of the widget sits in the Tab order, and the arrow keys move focus inside it, which keeps long widgets from flooding the Tab sequence.
Focus management compared with related techniques
Focus management works together with neighboring accessibility techniques, and confusing them leads to incomplete fixes. A skip link lets users bypass repeated navigation once per page, while focus management responds to every dynamic change.
Semantic structure provides the headings and landmarks that focus targets rely on, and live regions announce updates without moving focus at all. Moving focus is the stronger intervention: it should be used when the user must act on new content, while a live region suits status messages such as “Saved” that require no action.
Mistakes that break focus
Focus bugs are among the most frequent findings in accessibility audits of web applications, especially single-page applications. The typical failures are listed below.
| Symptom | Cause | Fix |
|---|---|---|
| Focus jumps to page top | Focused element was removed from the DOM | Move focus to a logical neighbor before removal |
| Tab reaches content behind a modal | Background not made inert | Apply inert or trap focus within the dialog |
| No visible focus ring | outline: none without replacement | Style :focus-visible with sufficient contrast |
| New view is silent | Client-side routing without focus handling | Focus the new main heading |
| Focus lost on modal close | Opener reference not stored | Save the trigger and restore focus to it |
Moving focus too often is also harmful. Unrequested focus jumps disorient users, so focus should move only in response to a user action or when the old position no longer exists.
Put simply
People who use a keyboard instead of a mouse move through a page one element at a time, like a cursor that marks “you are here”. Focus management makes sure that marker is always visible and always in a sensible place.
When a window pops up, the marker should jump into it. When the window closes, the marker should return to where the person was. Without that care, users get lost and have to start again from the top of the page.
In practice
A bank rebuilds its online transfer form as a single-page application. An audit with a screen reader user reveals that after pressing “Review transfer”, nothing is announced, and focus remains on a button that was removed, so the next Tab press lands at the top of the page.
The team changes the flow: after the view switches, focus moves to the heading “Review your transfer”, which has tabindex="-1". The confirmation dialog traps focus while open and returns it to the confirm button when closed, and validation errors focus an error summary with links to each field. Keyboard-only users now complete the transfer in a straight line, and the retest shows no focus-related WCAG failures.