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

Intent

For people such as those who have low vision or mobility impairments who use a keyboard or keyboard interface device (e.g., a switch, voice input), knowing the current point of focus is very important. However, when progressing through a page, other content may potentially hide the focused element. This Success Criterion ensures that the item receiving focus is not entirely hidden by other content created by the author.

Typical types of content that can overlap focused items are sticky footers, sticky headers, or non-modal dialogues. As a user tabs through the page, these layers of content can obscure the focused item, including the focus indicator. If the interface is configurable so that the user can move toolbars and non-modal dialogs around, then only the initial positions of user-movable content would be considered for testing and conformance of this success criterion.

This criterion allows for part of the focused element to be obscured as there can be practical reasons that part of a focused element is obscured. For best visiblity, none of the element or focus indicator would be hidden, see also Focus Not Obscured (Enhanced).

Ideally any overlap of the component receiving focus by other content will be avoided. However, in recognition of the complex responsive designs common today, the minimum version of this requirement requires only that where other content overlaps an item receiving focus, it not do so entirely. Typical types of content that can overlap focused items are sticky footers, sticky headers, or non-modal dialogs. As a user tabs through the page, these layers of content can obscure the focused item and its focus indicator.

A notification implemented as sticky content, such as a cookie banner, will fail this Success Criterion if it obscures an element with 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 (dismissed) on loss of focus.

Another form of obscuring can occur due to light boxes or other semi-opaque effects overlapping 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 2.4.11 Focus Appearance. When a focus indicator can be covered by a semi-opaque component, the ability of the focus indicator to pass 2.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.

Benefits

• This Success Criterion allows many who rely on a keyboard interface to operate the page by letting them visually determine the component on which keyboard operations will interact at any point in time. This includes people with low vision and/or mobility impairments, who may rely on a keyboard or keyboard interface including speech input, sip-and-puff software, onscreen keyboards, scanning software, and a variety of assistive technologies and alternate keyboards.
• 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 entirely hidden by the footer.

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.