Focus Not Obscured – Minimum and Enhanced requirements
Two variants of the Focus Not Obscured requirement were added in WCAG 2.2 – one at level AA and another at level AAA. These criteria stipulate that elements focused by keyboard input are not obscured by other content, so users can more easily navigate pages.
Benefits, impact, and intent of these success criteria
These requirements are primarily beneficial to sighted users navigating via keyboard interface. This is usually due to a mobility impairment meaning that a pointer input cannot be accurately controlled, or it would be painful or fatiguing to do so. Users who cannot use a mouse or other pointer input will navigate via keyboard interface, using the tab and shift + tab keys to move forwards and backwards through content, respectively. If a focused element is obscured by other content on the page, it could be difficult for these users to track their focus position within the content.
Many users with vision impairments also navigate via keyboard, and would benefit from the focused element always being visually clear. These requirements can also benefit users with attention or memory limitations, to whom it may be useful to discover or check where focus is placed on the page.
Voice control software such as Dragon NaturallySpeaking allows users to navigate and interact with page content through voice commands, these users sometimes use manual keyboard navigation voice commands to reach content. Keyboard navigation can also be emulated through switch inputs such as sip-and-puff devices, which send signals to computers based on inhaling and exhaling into a device. Therefore, accessible keyboard navigation also benefits users of these technologies.
How to meet these requirements
Content authors must ensure that users can navigate through the content via keyboard interface without losing track of the focused element due to other content obscuring it.
Quite often, managing focus behaviour to prevent focus moving behind elements (such as dialogs) is enough to meet these requirements. For other content such as headers and footers, scroll-padding may be needed.
Avoiding fixed position content where possible, especially for inline content such as expandable sections, will also make it easier to meet these requirements.
2.4.11 Focus Not Obscured (Minimum) (Level AA)
To meet this criterion, interactive elements must be at least partially visible on-screen when focused. At level AA, elements may be partially obscured by other content, as long as the entire element is not obscured. In practice, this means that users would be able to see which element is focused, but may not be able to determine the purpose of the element.
Success Criterion (SC)
“When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.”
2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
To meet the AAA criterion, every focused interactive element must be entirely visible on-screen when receiving keyboard focus. No part of the focused element can be obscured by other content, meaning the focused element and its purpose will be clearer to users.
Success Criterion (SC)
“When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.”
Techniques and examples
- Dialogs that cover other page content but do not trap focus can cause issues if focus can move behind the dialog. Trapping focus within dialogs until closed by the user ensures that focused elements are not covered by the dialog.
- Fixed or ‘sticky’ positioning for headers, footers, and other floating content often cause focused content within the main content to be obscured when the page scrolls up and down. Using scroll-padding can alleviate issues for fixed content, by ensuring that focused elements brought into the page view are not obscured.
- Custom popup elements such as list boxes or menu items may obscure focus if these elements remain visible after moving away from them. Dismissing or closing them when users leave the menus ensures they do not interfere with keyboard navigation.
- Dismissing floating content such as tooltips when users move focus away from them or their trigger elements ensures they do not obscure other focused controls.
- Reflowing or displacing existing content when new content appears on the page can be used to avoid obscuring focused elements
Advantages and limitations
These success criteria are welcome additions to WCAG 2.2, which represent issues previously not accounted for under the existing keyboard navigation criteria. It is possible to meet all other criteria relating to keyboard navigation and focus indicators, but for elements to be obscured when focused. Therefore, inclusion of these criteria allows for a more robust evaluation of keyboard navigation.
On some occasions, it could be very difficult to see or understand the focused element even when meeting the level AA (minimum) requirement. An element can be almost entirely obscured, but still meet WCAG 2.2 AA if it is partially visible. For this reason, we recommend always aiming to meet the Focus Not Obscured (Enhanced) requirement.
Exceptions and allowances
The level AA (minimum) requirement allows for user-movable and user-opened content to obscure focused elements in some circumstances. This provides flexibility for authors when implementing user-controllable content.
If content regions can be moved by users, it is possible that focused elements become obscured by the element depending on where the user moved it to. For example, a dialog may be implemented such that users can reposition it in a way which causes focused elements to be obscured. Content authors are only required to ensure that the focused element is not obscured when the movable content is in its initial position.
Author-created content which is opened by the user is permitted to obscure focused elements, as long as the user can reveal the focused element without moving keyboard focus, such as using the arrow keys or pressing the escape key to dismiss the obscuring content. For example, if the user opens a chat window which obscures focused elements, this is acceptable as long as the focused elements can be brought into view. This allowance does not apply to content which is automatically opened.
Relationships with other success criteria
There are a number of WCAG success criteria which involve keyboard navigation and focus indication; however, the Focus Not Obscured criteria are unique. The Keyboard and Focus Order criteria require that all functionality is available via keyboard interface, and that the order in which elements receive focus is logical and expected, without impeding operability. The visibility of focus indicators can represent issues under Focus Visible, Use of Colour, Non-text Contrast, or Focus Appearance. These requirements relate to the focus indicator directly, whereas the Focus Not Obscured requirements require that the interactive elements themselves are visible, regardless of their focus indicator.
Article by : Austin Hooper
DAC Technical Auditor