Clarification for Understanding 2.4.11 Focus Not Obscured (Minimum) to ensure consistent testing

[annethyme]

In a meeting between accessibility experts from several Scandinavian organisations, the following questions for 2.4.11 Focus Not Obscured were brought up.

The question is not so much what the suggested best practice for this is, but what the minimum requirements are in a legal/monitoring context.

Having written several ACT Rules for WCAG in the past, I also anticipate that further clarification will be needed before it is possible to agree on ACT Rules for this SC.

We suggest that Understanding SC 2.4.11 (and possibly techniques as well) is updated with information to help clarify these points.

What is the threshold for "not entirely hidden"? Should enough of the component be unobscured, that the user can identify what the component is and what it does? Or should it just be possible to identify that there is a component? Or is it enough that 1 pixel of the component is not hidden?

Which part (component, focus indication or both) has to be unobscured? The Intent of the Understanding document explains: "knowing the current point of focus is critical. The component with focus signals the interaction point on the page"

However, the SC states that this is about "the component is not entirely hidden". This means that the focus indication could be entirely hidden and this SC still pass, even though the "current point of focus" is not clear in this case. If the focus indication is positioned on one side of the element, e.g. as an underline, an arrow before etc. this scenario is not hard to imagine.

On the other hand, it is also not clear from the understanding document whether the focus indicator should be considered a part of the element, and having a portion of the focus indicator unobscured would be enough to pass this SC.

So is it enough that either the component or the focus indicator is unobscured? Or does both a part of the component AND something that indicates that it is currently focused have to be visible to pass this SC?

[patrickhlauke]

What is the threshold for "not entirely hidden"?

normatively, as written, I would suggest that if even a single pixel is visible/not obscured, that passes "not entirely hidden"

Which part (component, focus indication or both) has to be unobscured?

that's a bone of contention at the moment - with some arguments around the fact that the SC is scoped to the user interface component, and that strictly the focus indication is not necessarily part of the UIC itself. https://mastodon.world/@siblingpastry/110779943577047394

I personally would say that for the purposes of this SC, it should absolutely count as part of the UIC (otherwise it's pointless as an SC, since the UIC may be "not entirely hidden" but the actual focus indication could be, otherwise

[edit: and randomly, this conundrum is something I included in my recent talk]

[mbgower]

The question is not so much what the suggested best practice for this is, but what the minimum requirements are in a legal/monitoring context.

I concur with @patrickhlauke that the normative wording means that even a single pixel being visible is "not entirely hidden". A single pixel would be unhelpful to just about anyone, but it IS a clear and consistent test result.

Which part (component, focus indication or both) has to be unobscured?

Taken from a user perspective, if one cannot see any part of the focus indicator, one would not have any idea which component has keyboard focus. So, on first consideration it seems the indicator is what should be assessed.

However, at least one draft of AA and AAA versions differed in what was assessed, with the wording "focus indicator" being used in the AAA and "user interface component" (UIC) in the AA. They were made uniform, and both now use UIC, so the intent was clearly that it was the user interface component not the focus indicator that was to be assessed. Why?

First, many implementations of focus indicators fade at the edge, so if the wording only referred to the focus indicator, at the AA level, a single unobscured pixel with very low contrast would pass. So there would be no chance that anyone could possibly see this, even if quite a few very low contrast pixels were visible.

Second, we already have an SC, Focus Visible, requiring that "the keyboard focus indicator is visible". If the tests for Focus Not Obscured looked at the indicator, they seem redundant.

Third, the vast majority of focus indicators surround a UIC, so if at least a pixel of the UIC is not obscured, many pixels of the focus indicator should be visible. So putting the test on the UIC increases the chances that typically focused controls will have focus indicators that are at least partially visible.

Fourth, at the AAA level, requiring the entire UIC to be visible is highly likely to result in a good portion of the focus indicator also being visible. However, if the focus indicator is considered part of the UIC, then the AAA would fail where a single very low contrast fading pixel of a thick and prominent focus indicator happened to be obscured.

In conclusion, I believe that for the purposes of this SC, the UIC alone, and not additive pixels indicating its focused state, should be considered for both the AA and AAA versions of the SC.

---

Note that during a review of the technique, I noticed an issue with its test and have opened a new issue for that https://github.com/w3c/wcag/issues/3532

[mbgower]

The WCAG 2.x Task Force briefly discussed at our Friday meeting, with discussion centered on whether the focus indicator would be considered part of the UIC. Members will be adding their thoughts to this issue, before we arrive at a draft official response to bring to the Working Group.

[mbgower]

If I could change the titles of these SCs, I'd advocate that they be renamed: 2.4.7 Focus Indicator Visible 2.4.11 Focused Component Not Obscured

Even if we didn't alter the normative text itself, I think that would add clarity: 2.4.7 Focus Indicator Visible Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

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

[fstrr]

I am in the "the focus indicator is part of the User Interface Control" camp. Using the example of a button:

<button type="button">Bring me more cheese</button>

1. If I choose to make my focus indictor a change from normal-weight text to bold, the text inside the button is part of the UIC.
2. If I choose to make my focus indictor a change of the button's internal background color, that color is part of the UIC.
3. Focus is a state of a UIC, not the state of a separate thing that's controlled by the UIC.

[patrickhlauke]

1. If I choose to make my focus indictor a change from normal-weight text to bold, the text inside the button is part of the UIC.
2. If I choose to make my focus indictor a change of the button's internal background color, that color is part of the UIC.

those cases are simple and unambiguous. it's the very common "focus uses an outline that is technically outside of the UIC" case that is the one causing pearl-clutching

[eetukomsi-avi]

Thank you @annethyme and the Scandinavian experts for pointing this out.

I'd think this needs a change either in the criterion text or its title. That is because the title ("Focus Not Obscured") refers to the focus indicator, but the criterion text refers to the element only. So the title and the text emphasize the visibility of different things.

[eetukomsi-avi]

And in addition I think it's unclear how this criterion is intended to be interpreted e.g. in accessibility audition or supervision process.

If we read the criterion on how it explicitly states, it would be sufficient that a user can see one pixel from an element but not the focus indicator. So, in that case the user wouldn't see, what type of an element it is and doesn't even see if it has received a focus. Therefore the user wouldn't even know whether the element they partly see is focusable and they can't even know where the focus is on the page. So even if the obscuring element is a closabe modal or a cookie banner, the user wouldn't get any hint that they should close that element to see underlying content. If the user needs to pass multiple focusable elements that are positioned under another element (or elements) the user would have a hard time making any guesses where the focus has gone on the page.

Even if the criterion is intended to have a room for case-by-case interpretations about how visible the element needs to be to pass the criterion, that evaluation can't be made if the criterions intentions are unclear.

I think most would assume that all WCAG criteria are written with an idea that they'll have some effect on the output of digital content. So interpreting a critertion (especially an AA level criterion) in a way that it doesn't actually guarantee any improvents on accessibility doesn't feel like it's in line with WCAG's purposes. And as the criterion forms a couple with the AAA level criterion, we should also be able to understand where lies the border between these two.

If the idea really is that one can meet the AA level criterion just showing a couple vaque pixes from an element without even the knowlege that the element has received a focus and that the AAA level counterpart criterion means that not a single pixel from a focusable element's border can be positioned under another element (even though all information would be visibile) it doesn't feel like it's in align with intentions of other AA and AAA level criteria.

So I'd see that both criteria should have a bit more clarification whether their focus is on

• providing information that there's a (partially) hidden focusable element somewhere
• where that element in question is positioned on the page (i.e. what banner of modal should the user close to see the underlying element)
• what type of element it is (i.e. a button, a link, a checkbox...)
• what is the obscured element's purpose (i.e. what does a button do or where will a link lead to)

(The final question on the list of course focuses heavily on cognitive questions. How much one needs to see to be able to make a reliable guess on the element's purpose and how can this even be evaluated while there are a huge diversity on users? )

[patrickhlauke]

Even if the criterion is intended to have a room for case-by-case interpretations about how visible the element needs to be to pass the criterion

It doesn't

I think most would assume that all WCAG criteria are written with an idea that they'll have some effect on the output of digital content. So interpreting a critertion (especially an AA level criterion) in a way that it doesn't actually guarantee any improvents on accessibility doesn't feel like it's in line with WCAG's purposes.

however, keep in mind that WCAG is, for better or worse, a set of criteria "designed by committee", often starting out with very clear intentions, but then slowly watered down and rewritten to reach a lowest common denominator that is acceptable to all participants and organisations that take part in its creation (and down to a level that is realistic, i.e. not creating an SC that immediately makes 99% of the web fail).

[patrickhlauke]

If we read the criterion on how it explicitly states, it would be sufficient that a user can see one pixel from an element but not the focus indicator. So, in that case the user wouldn't see, what type of an element it is and doesn't even see if it has received a focus. Therefore the user wouldn't even know whether the element they partly see is focusable and they can't even know where the focus is on the page.

This sort of "even a single pixel would pass" scenario is not new ... I documented this previously for 2.4.7 Focus Visible (see slides 49 and 50 here https://patrickhlauke.github.io/wcag-interpretation/#49)