WCAG 2.2 release date is close (opens in new window), it will most probably happen this year in autumn. Nevertheless it brings new things that are positive for users, especially people with disabilities. Yes, it will take some time for it to be a part of laws and regulations, but when we consider people before compliance we need to prepare before it’s a part of official accessibility requirements.
For all developers interested into code examples, please check potential solution that is documented under Technique C43 – Using CSS margin and scroll-margin to un-obscure content (opens in new window). Remember thought that techniques are not a guarantee to fix your specific situation and please read on to get some introductory info.
Let me introduce you to 2.4.11 Focus Not Obscured (Minimum), an WCAG 2.2 AA success criterion
My main message is as reflected in the title of the post – 2.4.11 Focus Not Obscured is an AA level success criterion coming with WCAG 2.2 and it will bring more focus on how to make sticky elements more accessible. Not in a way that I mentioned in my previous post called “Sticky and fixed elements may cause huge accessibility problems“, but as it’s name suggests – making sure focus is not obscured even when interactive element is coincidentally behind sticky elements like always on top of the view navigation or always in the bottom of the view footers and other elements that persist scrolling. Special mention goes also to non-modal dialogs, so dialogs that are semantically not modals and can be ignored (not the ones that prevent interaction before making a choice or closing them, so to say). I would also add a navigation that is expanded over site and isn’t modal as an potential problem as well.
2.4.11 will need special attention when creating expanding navigation, cookie consents, wrongly coded modals and other non-modal content as well.
My reflection when thinking about the 2.4.11 and non-modal interface elements.
Now this is officially still a draft, the whole WCAG 2.2. currently is, but it really seems that it will soon be a requirement for web (and most likely also native mobile applications) when targeting conformance to WCAG on level AA. So let’s quickly introduce the new success criterion:
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Understanding SC 2.4.11 (opens in new window).
Author-created content in my interpretation is the interface and content, in combination and not only the content as it might be understood by some. That’s important to map it to responsibilities as it’s directed to mostly developers but also designers.
It comes with two notes and we need to mention them as well;
Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content are considered for testing and conformance of this Success Criterion.
First note for SC 2.4.11
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.
Second note for SC 2.4.11
But in this post I will not go into details about these two notes, to keep things short for the purpose of introduction.
So, briefly, we need to make sure that the focused item is visible (at least partially) even if it can potentially find itself under a sticky element. If user opens a modal it doesn’t need to be visible, as the user opened the modal intentionally.
Sometimes sticky elements improve user experience. Often they mean trouble and there are ways to improve the experience without sticky elements like menues (opens in new window), but sometimes we just need to implement them. And with the new WCAG success criterion 2.4.11 we will just have a bit more work to do to make it more accessible.
Issues that I mentioned in my old article “Sticky and fixed elements may cause huge accessibility problems” are still valid and please consider if you really need the stickies to stick, but when we need them we should also consider that they are not causing 2.4.11 to fail. But how to make sure we made stickies conformant?
How to prevent focus being obscured by sticky element, basics?
First thing to remember is that 2.4.11 requires only partial visibility of focusable user interface component. There is another success criterion, on level AAA, called 2.4.12 Focus Not Obscured (Enhanced) that requires no part of the focusable component is hidden. This distinction is important to understand how to make a solution:
- In case of non-modal dialogs, expanded navigation covering content and so on – make it modal (use correct semantics in the code, prevent user interaction behind, potentially use inert and so on).
- Using CSS scroll-padding (opens in new window), which can prevent overlapping other content. Scroll-padding has quite good support in browsers (opens in new window), by the way, unless you need support for Internet Explorer.
- In some cases we can close elements when they loose focus (for example expanding navigation, dialogs, chat components and so on), so that focus isn’t covered by them when it moves “behind” them. Should be very easy to implement.
To reach beyond basics and to gain better overview also around the two notes please read the whole Understanding SC 2.4.11 (opens in new window). There are a lot of details that I didn’t cover in this introduction but are important for understanding and finding solutions for your specific situations.
As digital interfaces get more complex we need to make sure that people with disabilities can also use them. Keyboard only users (and users of assistive technologies based on keyboard interfaces) depend on visible focus, so I am not surprised about this success criterion getting into WCAG 2.2. It is obvious that abundance of overlays, sticky elements, dialogs, menues, navigation and more made their experience much worse when focus was hidden behind other, inactive components.