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]

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 #3532

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.

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.

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.

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

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.

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

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

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)

@annethyme's :

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?

@mbgower 's:

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.

I overall agree with @mbgower 's assessment, however, the crux of this conversation is how is "not entirely hidden" defined which then leads to questions around visibility and perceivability.

For the sake of my questions, I'm defining visible to mean that the element is in view, regardless of whether or not it is perceivable. With this definition in mind, my question is:

Is this success criteria concerned with the contents or display of the component beyond being visible?

Consider the following cases:

• outline is calculated based on the box model, sitting at the boundaries of padding and border. A component may have sufficient padding such that only the padding and focus indicator is visible, however, it may mean that the element is not perceivable
• An image has built-in "white space" either through being a transparent png, gif, or svg or with a background color that matches the background, meaning that effectively, a user encounters the same scenario as the prior bullet

In either case, a user may not be able to perceive the component.

All this is to ask, what is the intent behind the SC, so that the normative language can be updated to reflect that?

Proposed (draft) response, phrasing as a group response rather than my personal thoughts:

What is the threshold for "not entirely hidden"?

If there are any pixel(s) of the component showing, that would constitute "not entirely hidden".

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

The criterion text states " the component is not entirely hidden". In the context of criteria such as focus-appearance, that does not include the focus-indicator. For example, if the focus indicator were included in the component for focus-appearance, then the metric for how large the indicator needs to be would change when the indicator is shown.

So in this case as well, the component does not include the focus indicator.

There is PR #4104 which adds a short note outlining the component does not include the indicator.

The second paragraph of the Intent section (in the understanding doc) does say that showing more is better, implying that anything showing would pass. We would rather not encourage people to skate close to the letter of the criterion.