Keep Keyboard Focus Visible and Unobscured
Sighted keyboard users need to see where they are. WCAG 2.2 requires a visible focus indicator that stays on screen—and is not entirely hidden by sticky UI.
A service website can look finished and still strand people who move with the keyboard. Tab once and the highlight vanishes. Tab again and the focused control sits under a sticky header or cookie banner. The page still “works” for mouse users. For sighted keyboard users—and for anyone using a switch or voice tool that drives the keyboard interface—the interaction point has gone missing.
WCAG 2.2 treats that as a measurable problem, not a taste preference. Three related success criteria define what “visible focus” means at Level AA and what a stronger indicator looks like at Level AAA.
1. The problem focus indicators are meant to solve
Keyboard navigation is a path through the interface. The focus indicator is the only reliable signpost for people who can see the screen but are not pointing with a mouse. Without it, users lose their place, activate the wrong control, or abandon the form.
An everyday analogy helps: imagine walking a hallway where the light that marks your position turns off after one second, or where a hanging sign fully covers the door you just reached. The corridor still exists; the navigation cue does not.
W3C’s Understanding document for SC 2.4.7 Focus Visible (Level AA) states the requirement in plain language: any keyboard-operable user interface has a mode of operation where the keyboard focus indicator is visible. Authors must provide at least one such mode. The indicator must not be time-limited—when keyboard focus is shown, it must remain visible.
That last clause matters on marketing sites that fade rings for “polish.” A focus cue that disappears on a timer fails the criterion’s intent even if it looked elegant in a mockup.
2. What WCAG 2.2 requires—and what it adds
Focus Visible (2.4.7, AA)
Definition: Keyboard-operable UI must have a mode where the focus indicator is visible and stays visible while focus remains.
Mechanism: Browsers may optimize when they show focus (for example, only after keyboard use). Authors are still responsible for ensuring a visible mode exists. Default browser outlines often work until CSS removes them.
Focus Not Obscured (Minimum) (2.4.11, AA — new in 2.2)
Definition: When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Intent (W3C): Sighted people who rely on a keyboard (or a device that uses the keyboard interface) must be able to see the focused item at least partially. Sticky headers, sticky footers, cookie banners, chat widgets, and non-modal overlays are common causes of total occlusion.
Mechanism: The criterion evaluates the focused component, not only the focus ring. If the control itself is completely covered, the criterion fails—even if a ring peeks out from behind the overlay. W3C notes that for best practice, none of the component should be obscured; the AA minimum is that it is not entirely hidden.
Focus Appearance (2.4.13, AAA)
Definition: When the keyboard focus indicator is visible, an area of that indicator is at least as large as a 2 CSS-pixel thick perimeter of the unfocused component (or sub-component), and that area has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
Exceptions (W3C): The criterion does not apply when the user agent determines the indicator and the author cannot adjust it, or when the author has not modified the focus indicator and the indicator’s background color.
AAA is not required for typical AA conformance claims. It is still useful design-system guidance: size and contrast turn “visible” into something auditors and low-vision users can rely on.
3. Failure patterns teams still ship
| Pattern | Why it breaks keyboard use | What W3C links it to |
|---|---|---|
outline: none / removing default focus with no replacement | No reliable cue for Tab order | Related to documented failures such as F78 (styling that removes or hides the visual focus indicator) |
| Script that clears focus on receive | Focus never settles where the user expects | Related to F55 (removing focus when focus is received) |
| Sticky chrome covering the active control | User cannot see the interaction point | SC 2.4.11 (component entirely hidden by author content) |
| Time-limited focus flash | Cue vanishes while focus remains | Conflicts with SC 2.4.7 “must remain visible” guidance |
A realistic studio scenario: a consultancy homepage uses a fixed top bar and a bottom cookie bar. Tabbing into the primary “Contact” button scrolls the control under the header. Mouse users never notice. Keyboard users see a page that appears stuck. The fix is layout and scroll behavior—not another decorative animation.
“A focus indicator that exists only in the stylesheet still fails if sticky UI swallows the control it marks.”
— Windware Studio Practice Note
4. Studio checklist before launch
Use this as a practical audit—not as invented CSS requirements:
- Tab the full inquiry path (nav → offer → form → submit) with the keyboard only.
- Confirm a visible indicator on every operable control; it must stay visible while focus remains (SC 2.4.7).
- Never remove default focus unless a clearly visible replacement is already in place.
- Check sticky headers, footers, cookie banners, and chat widgets so the focused component is never entirely covered (SC 2.4.11).
- Prefer a strong indicator that approaches Focus Appearance guidance: roughly a 2px-perimeter-scale change with ≥3:1 contrast between focused and unfocused states (SC 2.4.13 as a design target).
- Retest after responsive tightening—mobile sticky bars often create new occlusion.
- Document intentional exceptions (unmodified user-agent controls) so they are not silent gaps.
Limitation to keep explicit: Passing 2.4.7 and 2.4.11 does not certify overall accessibility. Labels, contrast, target size, and skip links remain separate requirements. Focus visibility is one operable gate in a larger system.
5. What to do on your next build
- Treat focus styles as a design-system token, not a last-day QA patch.
- Design sticky regions with keyboard scroll in mind (enough padding or scroll offset so focused controls stay partially visible).
- Ban “remove outline for aesthetics” unless a stronger replacement ships in the same change.
- Aim past the AA floor on primary actions—size and contrast help more people than a hairline ring.
Keyboard focus sounds like a narrow front-end detail. On a business site it is the difference between an inquiry path that can be completed without a mouse and one that only works for precise pointer users.
Ready to Discuss Your Website?
If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.
- Explore Our Services: Web Design · Web Development · Website Redesign
- Start a Conversation: Tell us about your project via our Contact Form or email us directly at
[email protected].