Understanding WCAG SC 2.4.11 Focus Not Obscured (Minimum)
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Note: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content is considered for testing and conformance of this Success Criterion.
Note: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.
This success criterion states that any element receiving keyboard focus and is identifiable by the user through a visible focus indicator must always be visible to users even when author-created contents/dynamic user interface elements open.
In situations where sticky headers, footers, popups created by email signup forms, chatbots, etc., are present, certain parts of the webpage might be obscured, hindering user access. Some of these interactions, while integral to modern design, are non-modal dialogs. Consequently, users may navigate to elements hidden by newly appearing content blocks using tab and shift-tab keystrokes. However, in such cases, users are unable to identify which element has received keyboard focus or which element is currently in focus, impeding their ability to take necessary actions.
Since the content block causing the obstruction is controlled by the content author, it is the author’s responsibility to ensure that all interactive elements, when focused via keyboard, are accompanied by a visible focus indicator and are not hidden by any other content block.
There are a few user interface elements like toolbars in a content authoring tools, chatbots, etc. in which the users are allowed to reposition such content blocks on the screen at their comfort. The SC notes that in such user-repositioned elements, the point of assessment/testing is the default position of the toolbar or chatbot and not the repositioned space. For example, a web page has a chatbot. By default, the chat trigger is positioned at the bottom of the page. But when the users open the chatbot, it opens at the center of the page and obscures the primary content of the page itself. Given this scenario, the default chatbot position is the point of testing and it fails. However, the web page allows the users to drag the bot window and dock wherever they want within the visible area of the screen. That repositioned chatbot does not fail this success criterion.
Points To Ponder
- Visibility is Key: Make certain that all elements remain visible when they receive keyboard focus and are not obscured by other content blocks.
- Partial Focus: In cases where maintaining full visibility of an element is not feasible, ensure a partial focus indicator is visible to the user.
- Sticky Elements and CSS Scroll-Padding: When utilizing sticky elements, utilize the CSS scroll-padding property. This property enables you to set padding on all sides of an element simultaneously.
Related Reads
Thanks to Sathish Kumar for reviewing and contributing to this article.
