Skip to content

Understanding SC 2.4.11:Focus Not Obscured (Minimum) (Level AA)


This understanding document is part of the draft WCAG 2.2 content. It may change or be removed before the final WCAG 2.2 is published.


The intent of this Success Criterion is to ensure that the item receiving keyboard focus is always partially visible in the user's viewport. For sighted people who rely on a keyboard (or on a device that operates through the keyboard interface, such as a switch or voice input), knowing the current point of focus is critical. The component with focus signals the interaction point on the page. Where users cannot see the item with focus, they may not know how to proceed, or may even think the system has become unresponsive.

In recognition of the complex responsive designs common today, this AA criterion allows for the component receiving focus to be partially obscured by other author-created content. A partly obscured component can still be very visible, although the more of it that is obscured, the less easy it is to see. For that reason, authors should attempt to design interactions to reduce the degree and frequency with which the item receiving focus is partly obscured. For best visibility, none of the component receiving focus should be hidden. This preferred outcome is covered by the AAA criterion Focus Not Obscured (Enhanced).

Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs. As a user tabs through the page, these layers of content can obscure the item receiving focus, along with its focus indicator.

A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it entirely obscures a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content. Notifications that do not require user action could also meet this criterion by closing on loss of focus.

Another form of obscuring can occur where light boxes or other semi-opaque effects overlap the item with focus. While less than 100 percent opacity is not causing the component to be entirely hidden, such semi-opaque overlaps may cause a failure of 1.4.11 Non-text Contrast. When a focus indicator can be covered by a semi-opaque component, the ability of the focus indicator to pass 1.4.11 should be evaluated (and pass) while the focus indicator is under the semi-opaque component. The intention in both situations is that the component receiving focus should never be obscured to the point a user cannot tell which item has focus.


  • Sighted users who rely on a keyboard interface to operate the page will be able to see the component which gets keyboard focus. Such users include those who rely on devices which use the keyboard interface, including speech input, sip-and-puff software, on-screen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.
  • People with limited or low vision but who rely upon a pointing device (for viewport orientation and repositioning) benefit from a visible indication of the current point of keyboard interaction, especially where magnification reduces the overall usable portion of content.
  • People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to more easily discover where the focus is located.


  • A page has a sticky footer (attached to the bottom of the viewport). When tabbing down the page the focused item is not completely hidden by the footer because content in the viewport scrolls up to always display the item with keyboard focus using scroll padding.
  • A page has a full-width cookie approval dialog. The dialog is modal, preventing access to the other controls in the page until it has been dismissed. Focus is not obscured because the major portion of the cookie approval dialog remains on screen (until selections are made and submitted), and so the major portion of the keyboard focus indicator remains visible.
  • A notification is implemented as a sticky header and the keyboard focus is moved to the notification so at least part of the focus indicator is in view. The notification disappears when it loses focus so it does not obscure any other controls, and part of the prior keyboard focus indicator is visible.


Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

  1. C43: Using CSS margin and scroll-margin to un-obscure content Using CSS margin and scroll-margin to un-obscure content


The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

  1. F110: Failure of Success Criterion 2.4.11 due to a sticky footers or headers hiding focused elements

Key Terms

user interface component

a part of the content that is perceived by users as a single control for a distinct function


Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.


User interface components include form elements and links as well as components generated by scripts.


What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

Back to Top