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).

Partially obscuring an element (e.g., covering half of it) does not fail 2.4.11, although it would fail SC 2.4.12: Focus Not Obscured (Enhanced) at AAA, which requires that no part of the control is obscured under the same circumstances.

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.

SC 2.4.7 Focus Visible doesn’t cover the possibility of elements being temporarily obscured, because it’s only concerned with content having a mode of operation where the keyboard focus indicator is visible. If a focused element is temporarily obscured, then it still has a mode of operation where the focus indicator is visible, therefore it wouldn’t fail 2.4.7.

Individual failures of 2.4.11 are not applicable for 2.4.7 (assuming they otherwise pass). However elements that already fail 2.4.7 due to having no visible focus indicator, can still fail 2.4.11 as well, and must still be tested.

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.



Image credit: Azlan DuPree.

Categories: Accessibility Strategy, KnowledgeBase Content, Technical

About James Edwards

I’m a web accessibility consultant with around 20 years experience. I develop, research and write about all aspects of accessible front-end development, with a particular specialism in accessible JavaScript. I can also turn my hand to PHP and MySQL when it’s needed. I started my career as an HTML coder, then as a JavaScript developer, but the more I learned, the more I realised just how important it is to consider accessibility. It’s the basic foundation of web development and a fundamental design principle of the web itself. If information is not accessible, then what’s the point of any of it? Coding is mechanics, but accessibility is people, and it’s people that actually matter.


Dan Tripp says:

RE: “This SC can be entirely tested by automation, and is the only WCAG 2.2 criterion that can.” – the ACT group has made progress ( on automating ‘target size minimum’. Any thoughts?

Dan Tripp says:

Following up on my previous comment: I just noticed that you already discussed this at