Accessibility
Focus Management
Keyboard focus must be visible at all times, move in a logical order, and be actively managed when content changes — especially when modals open, overlays appear, or dynamic content updates.
Where it comes from
It's anchored in WCAG 2.2, across two success criteria: SC 2.4.7 (Focus Visible, Level AA) requires a visible focus indicator on keyboard-operable elements, and SC 2.4.11 (Focus Appearance, Level AA, new in WCAG 2.2) sets a minimum size and contrast for that indicator.
Why it matters for your website
Focus management is the active responsibility to ensure that keyboard users always know where they are on a page and can reach everything they need. WCAG 2.2 addresses this across two success criteria: SC 2.4.7 (Focus Visible, Level AA) requires that any keyboard-operable interface has a visible focus indicator; SC 2.4.11 (Focus Appearance, Level AA, new in WCAG 2.2) specifies minimum size and contrast for that indicator. Beyond the static page, focus management becomes critical wherever content changes dynamically: when a modal opens, focus must move into it and be trapped there until dismissed; when a modal closes, focus must return to the element that triggered it; when a page section updates, focus should move to the new content or an appropriate announcement. For keyboard and screen reader users, an interface that does not manage focus actively is an interface where they can be stranded at any moment — inside dialogs they cannot exit, or at page positions that no longer relate to what is on screen.
Focus management is an active responsibility, not just a styling choice. On a static page it means a visible focus indicator at all times, moving in a logical order; but the moment content changes dynamically, focus has to be deliberately moved.
The dynamic cases are where it's most often broken. When a modal opens, focus must move into it and be trapped there until dismissed; when it closes, focus must return to the element that opened it; when a section updates, focus should move to the new content. An interface that doesn't manage focus can strand keyboard and screen-reader users — inside dialogs they can't exit, or at positions that no longer relate to what's on screen.
Wrong vs right
A modal that opens without moving focus into it, leaving keyboard users still focused on the page behind.
Focus moved into the modal on open, trapped until dismissed, then returned to the trigger on close.
A focus indicator that's invisible or too faint to see, so keyboard users lose their place.
A clearly visible focus indicator meeting WCAG 2.2's size and contrast requirements.
A dynamic content update that leaves focus stranded at a position unrelated to what's now on screen.
Focus moved to the new content (or announced), so the user stays oriented.
Understanding Focus Management
Focus management is the active responsibility of ensuring keyboard users always know where they are on a page and can reach everything they need. WCAG 2.2 addresses it across two criteria: SC 2.4.7 (Focus Visible, Level AA) requires any keyboard-operable interface to show a visible focus indicator, and SC 2.4.11 (Focus Appearance, Level AA, new in WCAG 2.2) specifies a minimum size and contrast for that indicator.
On a static page, that means a focus indicator that's always visible and moves in a logical order. But focus management becomes critical wherever content changes dynamically. When a modal opens, focus must move into it and be trapped there until it's dismissed; when the modal closes, focus must return to the element that triggered it; when a section updates, focus should move to the new content or an appropriate announcement.
The consequence of neglecting this is severe. An interface that doesn't actively manage focus can strand keyboard and screen-reader users at any moment — inside dialogs they cannot exit, or at page positions that no longer relate to what's on screen. It's the dynamic counterpart to keyboard navigability, and it connects to the POUR principles.
How Kweri checks it
Focus management spans the automatable and the deeply interactive. Kweri's automated checks can catch some static issues — missing or insufficient focus indicators, for instance — which are measurable. But the heart of focus management is dynamic behaviour: whether focus moves into a modal, is trapped, returns to the trigger, and follows content updates — and that only reveals itself when you operate the interface with a keyboard. So Kweri can flag missing or weak focus indicators, while being explicit that verifying focus behaviour around modals, overlays, and dynamic updates requires hands-on keyboard and screen-reader testing.
FAQ
What is focus management?
Focus management is the active responsibility of ensuring keyboard users always know where they are and can reach everything they need — keeping focus visible, in a logical order, and deliberately moving it when content changes, such as when modals open and close.
What does WCAG 2.2 say about focus?
Two criteria: SC 2.4.7 (Focus Visible, Level AA) requires a visible focus indicator on keyboard-operable elements, and SC 2.4.11 (Focus Appearance, Level AA, new in WCAG 2.2) sets a minimum size and contrast for that indicator so it's actually perceivable.
How should focus behave when a modal opens?
When a modal opens, focus must move into it and be trapped there until it's dismissed; when it closes, focus must return to the element that opened it. This keeps keyboard and screen-reader users oriented and prevents them being stranded.
What happens if focus isn't managed?
Keyboard and screen-reader users can be stranded at any moment — trapped inside dialogs they can't exit, or left at page positions that no longer relate to what's on screen. Active focus management prevents these dead-ends.
How is focus management different from keyboard navigability?
Keyboard navigability is about being able to reach and operate everything by keyboard; focus management adds the active handling of where focus is and how it moves, especially as content changes dynamically. They're complementary parts of keyboard accessibility.
Related principles
Every interactive element must be reachable and operable using a keyboard alone, with visible focus indicators showing where the user currently is.
Web accessibility is organised around four principles: content must be Perceivable, Operable, Understandable, and Robust — failure on any one principle makes content inaccessible to some users.
Always tell users what's happening, with clear feedback delivered in good time.
People miss changes that happen outside their current focus of attention.
Attribution & sources
Identified by W3C Web Accessibility Initiative (WAI). Catalogued from W3C — WCAG 2.2: Focus Visible & Focus Appearance.
Based on WCAG 2.2 SC 2.4.7 and 2.4.11; the linked W3C reference is used here.
See Focus Management on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →