Understanding SC 2.4.11:Focus Not Obscured (Minimum) (Level AA)
In brief
- Goal
- Keep the focused item visible.
- What to do
- Ensure when an item gets keyboard focus, it is at least partially visible.
- Why it's important
- People who can't use a mouse need to see what has keyboard focus.
Intent
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.
User-movable content
This SC contains a note regarding content that can be repositioned. If users can move content regions, then they can potentially position the movable content such that it obscures other content that may receive focus. In such a case, the author is only responsible for ensuring that the movable content in its initial position does not obscure the item receiving focus.
This note is intended to accommodate a common interaction in complex applications such as authoring tools, where the main editing region (also called a canvas) can be enhanced by displaying toolbars or other panels, which can be repositioned around the canvas. It is possible to design such toolbars so they do not obscure focus. Authors are encouraged to do so, as well as pursue techniques which ensure equitable keyboard use of such toolbars. However, in recognition of the complexities involved in responsive design as well as in supporting the ability to transform the text size and spacing of content, only the starting position of such movable panels is assessed.
User-opened content
This SC contains a note regarding content that is opened or disclosed by the user. One example of such content is a menu button opened by a user that opens a list of choices over pre-existing content on the screen. Such content can obscure other information on the screen, but it does not obscure an item receiving keyboard focus, because the new content doesn't stay open through a change of focus. However, authors may create user-opened content that is intentionally designed to persist until closed by the user, such as a chat window. Such persistent content has the potential to fail Focus Not Obscured (Minimum). Various types are described in this section. All can be designed so that they pass this Success Criterion.
In recognition of more complex applications, the note allows for user-opened content to obscure the item receiving focus, provided the user can bring the item with focus into view without actually altering the keyboard focus. Keyboard actions that may allow the item with focus to be revealed include: 1) using Esc to dismiss the opened content, 2) using keys to scroll the content in the viewport to reveal the item with focus, or 3) issuing a key to move between overlays. The rationale is that if a user opens a toolbar or chatbot, they have some context to understand why other content may be obscured by it.
This section only applies to content that the user actively discloses. Content pre-positioned by the author (such as a sticky footer), or content that appears without direct user initiation, such as system warnings, must not prevent the item receiving focus from being immediately visible in the viewport. Also, this note is not intended to apply to disclosures that are by convention non-persistent. As discussed in the following sub-section, an open dropdown that does not close when no longer focused is not following this convention.
Non-persistent opened information
A number of components on the web open (or disclose) additional content (on activation or on focus) intended for immediate user interaction or information. This new content is often on top of other content, obscuring it. Examples of such components are menu items, select element items, combobox lists (and other dropdown items), date picker calendars, and tooltips. The common trait of all these components is that they are not expected to persist after being acted on or once they are no longer the primary point of user interaction. Such non-persistent disclosures do not fail this SC since they do not obscure the item with focus. However, if an author allows such components to persist after the user has 1) activated one of the opened items or 2) moved the focus away from the triggering item and the additional content, it is at risk of failing this criterion by obscuring the item with focus.
User openable, persistent disclosures
Some disclosure patterns provide a mechanism for the user to open additional content that remains open until intentionally closed by the user. Accordions are a simple example of such a pattern. Chatbots and expandable side navigation are more complex examples. All of these patterns can be implemented so they are not at risk of failing this SC. Some possible approaches are:
- When the additional content appears, it displaces existing content. An accordion is an example of this. When an accordion is opened, the disclosed content
shifts existing content further down the page. Since the new content does not obscure
existing content, it cannot obscure the item with focus.
- When the additional content appears, existing content reflows. The popout sidebar on the WCAG standard is an example of this pattern. When the side menu is activated, it opens a new section
of information along the left side of the page. The main content area is reduced horizontally
to accommodate the new content, and the existing content reflows to fit in the thinner
space. As a result, there is no overlapping content between the two sections; the
item receiving focus, whether in the left navigation or in the main content, will
not be obscured by the other section.
-
When the additional content is opened, it takes focus and the tab ring is constrained
to the new content until it is dismissed. This modality is somewhat like a dialog, in that a user cannot navigate beyond the
opened content by keyboard without dismissing it first (typically by pressing Esc).
However, unlike in a modal dialog, in some implementations a pointer user may be able
to interact with content outside the opened section without dismissing it. Since this
pattern potentially creates an inequitable experience between keyboard and pointer
users, it should be used cautiously. That said, it does prevent the opened content
from obscuring the keyboard focus in the main content, and thus should pass this SC.
This is described and demonstrated in a short video in the Knowbility article in the
reference section, under the section heading Keep keyboard focus in the slide-out navigation until it's closed.
-
The disclosure expands into an area of the page containing no other content. Many pages are designed with wide margins, providing significant white space into
which new content can be opened. Many chatbots and toast notifications are designed
to 'slide up' into the right unpopulated side of a page. Where authors are careful
to ensure content is not obscured at each breakpoint in a responsive design, no obscuring
of other operable content need occur.
-
When focus leaves the additional content, the additional content is hidden or collapsed. This is very similar to patterns discussed previously under Non-persistent opened
information. A distinguishing factor can be that the user's last point of interaction
in the disclosure is preserved (it persists) even though it may be hidden until a
user returns. Some trees and left navigation patterns behave this way.
Where opened content persists and causes existing content to be obscured, it will be at risk of failing this criterion if it prevents users from seeing the item receiving focus. An example of this problem is described and captured in a short video in Slide-out navigation stays open while focus is on content behind it.
Modal dialogs
A properly constructed modal dialog will always pass this SC. Even if it appears directly on top of an item with focus, the dialog takes focus on appearance, and thus the item receiving focus -- the dialog or one of its components -- is visible. A properly constructed modal maintains that focus and prevents interaction outside the modal until it is dismissed.
A dialog-like overlay that does not take focus on appearance and does not either constrain interaction to the overlay or dismiss itself on loss of focus (thus allowing focus to exit into the content behind it) will be at risk of failing this SC, where it is positioned such that it can obscure other focusable items.
Benefits
- 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 a keyboard or on devices which use the keyboard interface, including speech input, sip-and-puff software, onscreen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.
- People with limited or low vision, who may primarily user a pointer for screen orientation and repositioning, nonetheless benefit from a visible indication of the current point of keyboard interaction, especially where magnification reduces the overall viewing portion of the screen.
- People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.
Examples
- 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.
Related Resources
Resources are for information purposes only, no endorsement implied.
Techniques
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
Failures
The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.
Key Terms
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".