How to test 2.4.11: Focus Not Obscured (Minimum)

Continuing our series of articles on how to test the new Success Criteria (SC) in WCAG 2.2.

Detailed conformance and testing information can also be found in KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Essentials or Enterprise tier subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.

Success Criterion 2.4.11: Focus Not Obscured (Minimum) requires that interactive controls are not entirely obscured by author-created content, at the point when they receive focus. It only applies to elements when they receive focus, not just to any element that might become focused, nor to elements that are already focused when obscuring content appears.

This benefits all keyboard users, particularly some users with cognitive or memory impairments, by ensuring that it’s easy to identify where the focus position is.

Normative requirements

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

This issue can most commonly occur with things like sticky headers and non-modal dialogs. For example, if you have a page with a sticky header, and tabbing back through the page causes the sticky header to entirely obscure an element when it receives focus, then it fails this SC.

The definition of user interface component is not specific as to markup or implementation, it refers to whatever the user perceives as a single control. For example, composite widgets like sliders, which have an interactive thumb inside a larger track, should be considered a single control (i.e., the whole slider, not just the thumb).

There are notes for this SC that provide two specific exceptions:

Content that’s been repositioned by the user. If users can move content regions, like draggable cards and toolbars, such that they obscure another element when it receives focus, then the focused element doesn’t fail, because the user caused that state. Only the initial position of the moveable content is considered (i.e., its position at page load).

Content that’s been opened by the user, but which can be dismissed without moving focus. For example, a click-triggered top menu that’s intended to remain persistent until the user closes it, wouldn’t fail when an element underneath receives focus, if (and only if) the user can close the menu without moving focus, such as by pressing ESC. This only applies to user-triggered content, it doesn’t provide a more general exception. For example, if focus is obscured by a sticky header, it doesn’t pass simply because the user can scroll it away with arrow keys.

Practical ambiguities

An element’s focus indicator is not included in the definition of user interface component. If the element’s content is entirely obscured, but the edge of its focus indicator is visible, then this is still considered to be entirely obscured, and therefore fails this criterion.

If the obscuring content is semi-transparent, such that it does cover the element receiving focus, but it’s still possible to see that element because of the transparency, then this doesn’t fail. However the resultant color of its focus indicator should be tested against SC 1.4.11: Non-text Contrast.

Testing barriers

Testing for this SC benefits from the ability to make visual and spatial comparisons.

To identify visually overlapping content, you would need to be able to see it, and identify that it’s overlapping. However this is not a hard barrier if automated testing is available.

Automated testing

This SC can be entirely tested by automation, and is the only WCAG 2.2 criterion that can.

I had hoped to be able to demonstrate a script to perform this automated testing, however I’m still working on that, because it turned out to be a lot more complex in practice than it seemed in theory. Here’s the theory:

1. Identify all focusable elements on the page.
2. Exclude those which are invisible, undisplayed, or have no rendered appearance (e.g. zero size, or not rendered at all).
3. Programmatically focus each element in turn, iterating over the whole page twice (top to bottom, bottom to top). Then for each element as it receives focus:
   1. Identify all elements whose bounding box coordinates contain the focused element’s top-left coordinate, and are visually above it in the paint order.
   2. Exclude those which are invisible, undisplayed, have no rendered appearance, are semi-transparent, have a transparent or semi-transparent background, or are direct descendants of the focused element.
   3. Compare the two coordinate sets to evaluate whether the focused element’s coordinates are entirely inside those of the superimposed element (the bounding box coordinates, not the bounding boxes themselves).
   4. If they are, this focusable element fails.

The difficult part is getting the paint order of elements, since there’s no DOM API that provides this information. The closest we have is elementsFromPoint, however that only includes elements which are pointer interactive. So for example, it excludes elements with pointer-events: none, and it would exclude those where the identifying coordinates are outside the element’s border-radius (since the space between the radius and the bounding box is not pointer interactive).

So far as I can figure out, the only way to get the necessary information, is to implement a custom API that provides a list of elements in paint order. This would have to mediate all possible CSS stacking contexts, as well as accounting for things like transforms and filters. Which is … erm … complicated!

But it is possible, and my colleague Cédric Trévisan has already done a lot of work on building such an API (which can be useful for other automation tasks too, such as testing the contrast of colors produced by layer blending).

I’ll write more about this when I have a functional solution.

Manual testing

Manual testing can be performed in the following steps:

1. Manually TAB and SHIFT+TAB through all focusable elements (i.e. test in both directions for the entire page).
2. Visually verify that no focused element is entirely obscured by author-created content at the point when it receives focus (or one of the note exceptions applies).
3. If the design is responsive, repeat the testing steps for each responsive breakpoint.

Yielding one of three expected results:

• Pass: No focused elements are entirely obscured at the point when they receive focus, or an exception applies to those which are.
• Fail: One or more focused elements are entirely obscured at the point when they receive focus, and no exceptions apply.
• Not Applicable: There are no focusable elements.

Glossary

• User interface component
• Normative

Resources

• Understanding SC 2.4.11: Focus Not Obscured (Minimum) (Level AA)
• Understanding SC 2.4.11: Focus Not Obscured (Enhanced) (Level AAA)
• Understanding SC 1.4.11: Non-text Contrast (Level AA)
• Understanding SC 2.4.7: Focus Visible (Level AA)
• Accessibility Testing with WCAG 2.2 (Webinar Video)
• Accessibility Testing with WCAG 2.2 (Webinar Transcript)
• New Success Criteria in WCAG 2.2
• Prevent focused elements from being obscured by sticky headers

Image credit: Azlan DuPree.