Home / Knowledge Base / Why Keyboard Focus Must Be Fully Visible (Enhanced)

Why Keyboard Focus Must Be Fully Visible (Enhanced)

Focus Not Obscured (Enhanced) ensures that when users navigate with a keyboard, the item that receives focus is fully visible on screen. Unlike the Level AA requirement, this criterion does not allow partial visibility. If any part of the focused component is hidden by overlapping content, the criterion fails.

A Quick Primer

Keyboard focus
Keyboard focus is the currently active element on a page, the link, button, or input that will respond if the user presses Enter or Space.
Focus typically moves forward with Tab and backwards with Shift+Tab. A visible outline or highlight usually indicates it.

Viewport
The viewport is the visible portion of the page on screen. At high zoom levels or on small devices, the viewport may show only a small area at a time.

Author-created content
This includes content positioned or layered by the site itself, such as sticky headers, footers, banners, chat widgets, or overlays. Browser UI does not count.

WCAG Success Criterion

2.4.12 Focus Not Obscured (Enhanced) (Level AAA)

When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

Why This Matters

For sighted users who rely on a keyboard, focus is the only visual signal of where interaction will occur next.

If even part of the focused component is hidden:

  • Users may misidentify which element has focus
  • Users may activate the wrong control
  • Users may lose orientation, especially at high zoom levels
  • Users may assume the interface is malfunctioning

When only part of a component is visible, users may not know its full size, label, or boundaries, especially when zoomed in or navigating dense layouts. At Level AAA, WCAG aims to eliminate this ambiguity.

Who This Helps

This criterion particularly benefits:

  • Keyboard-only users
  • Screen magnifier users
  • Users of speech input or switch devices
  • Users with low vision
  • Users with attention or short-term memory limitations
  • Users navigating dense or layered interfaces

What “Enhanced” Means

This criterion strengthens Focus Not Obscured (Minimum) by removing all tolerance for overlap.

LevelRequirement
AA (2.4.11)Focused component must be at least partially visible
AAA (2.4.12)Focused component must be fully visible

If any portion of the component is covered, even slightly, the enhanced criterion fails.

Intent of the Criterion

This success criterion intends to ensure users can always see the entire component that currently has keyboard focus.

Modern layouts often include overlapping elements such as:

  • Sticky headers and footers
  • Cookie banners
  • Non-modal dialogs
  • Floating notifications

At Level AAA, these patterns must be designed so they never overlap the focused element at all.

Because modern interfaces rely heavily on overlays and fixed positioning, meeting this criterion often requires deliberate layout trade-offs and may not be feasible for all interfaces.

Common Causes of Partial Obscuring

Partial obscuring commonly occurs when:

  • Sticky headers overlap the top of focused content
  • Sticky footers cover the bottom of buttons or links
  • Banners slide in without repositioning page content
  • Non-modal dialogs remain open as focus moves behind them
  • Chat widgets overlap form fields or navigation items

At Level AA, these may pass.
At Level AAA, they do not.

Focused Component vs Focus Indicator

This criterion evaluates the focused component itself, not the focus indicator, unless the indicator is part of the component.

That said:

  • If the focus indicator is fully obscured, 2.4.7 Focus Visible likely fails
  • In practice, strong AAA implementations ensure both the component and its focus indicator remain unobscured

Semi-Opaque Overlays (Important Clarification)

Semi-opaque overlays are not evaluated under this criterion unless they physically cover the focused component.

However, they may still cause failures under:

  • 1.4.11 Non-text Contrast
  • 2.4.7 Focus Visible
  • 2.4.13 Focus Appearance

Across all criteria, the goal remains the same: users must be able to clearly identify the focused element.

Modal Dialogs (Special Case)

A properly implemented modal dialog generally passes this criterion because:

  • The dialog takes focus when it appears
  • Focus is constrained within the dialog
  • The focused element inside the dialog is fully visible

Failures occur when:

  • Dialog-like overlays do not take focus
  • Focus can escape behind the overlay
  • Internal dialog content scrolls and clips focused controls

Relationship to Other Criteria

Focus Not Obscured (Enhanced) works closely with:

  • 2.4.11 Focus Not Obscured (Minimum) — baseline visibility
  • 2.4.7 Focus Visible — focus indication
  • 2.4.13 Focus Appearance — focus size and contrast
  • 1.4.11 Non-text Contrast — visibility under overlays

At Level AAA, these criteria reinforce one another to remove ambiguity entirely.

Examples

Passing example

  1. A page has a sticky footer.
    As users tab through the page, content scrolls so the focused element is completely visible above the footer at all times.
  2. A large cookie consent dialog appears and takes focus.
    The dialog remains fully visible until dismissed, and no background content receives focus.

Failing example

A sticky header partially overlaps the top of a focused link.
Even though most of the link is visible, any overlap causes failure at Level AAA.

Rule Description

When a component receives keyboard focus, no part of that component may be hidden by author-created content. Partial obscuring is not permitted.

The Algorithm

  1. Navigate the page using only the keyboard
  2. Move focus to each interactive component
  3. Check whether the entire component is visible
  4. If any part is hidden by overlapping content:
    • The criterion fails

How to Avoid Focus Obscuring (AAA)

  • Reserve space for sticky headers and footers
  • Use scroll-padding and scroll-margin consistently
  • Reflow content instead of layering it
  • Ensure persistent UI never overlaps focusable elements
  • Test at high zoom levels and small viewports
  • Treat overlays as modal where appropriate

How to Test This

  • Navigate using Tab and Shift+Tab
  • Test with all sticky UI enabled
  • Zoom to 200% or more
  • Verify focused elements are fully visible at all times
  • Confirm no overlap occurs at any breakpoint

Wrapping Up

Focus Not Obscured (Enhanced) removes guesswork. At Level AAA, users should never have to wonder whether they are interacting with the correct element. If the focus moves, it must be fully visible at all times. Overlapping content can still exist. Overlapping focus cannot.

Level AAA success criteria are not required for WCAG conformance claims and are often used as aspirational goals or internal quality benchmarks. This criterion represents the highest standard of clarity and predictability for keyboard interaction in complex interfaces.

Want to test against all WCAG success criteria?

Stay compliant. Avoid fines. WebYes reviews your entire website so you don't have to worry.

Sign Up for Free Now