2.4.11 Focus Appearance (Minimum) - adjacent contrast and unobscured clauses

[patrickhlauke]

Wondering if the "adjacent contrast" clause is necessary at all, as I would have thought that this is already covered by non-text contrast SC, making this redundant. Also, non-text contrast SC has no "escape clause" about 2px thickness - so would there be situations where a focus indicator nominally passes this adjacent contrast clause due to 2px thickness, but would nonetheless fail non-text contrast?

Talking about the thickness here also implies that the assumption of thie focus indicator is a line or border. What's the "thickness" of the whole control changing color (provided it contrasts sufficiently with the non-focused control)? It would be odd/inapplicable to talk about a "thickness" in that case.

"Unobscured: The item with focus is not entirely hidden by author-created content." so in theory if a single pixel is showing, it counts as not being obscurbed? this may be a bit too lax/pointless?

[RavenAlly]

I think your query about focus style thickness (para 2) when the whole control changes colour is covered by the first clause of Adjacent Contrast:

The focus indication area has a contrast ratio of at least 3:1 against all adjacent colors for the minimum area or greater, or...

If the focus indication area is the entire control then thickness doesn't come into it.

I agree that the first part of the adjacent contrast clause seems to be redundant (covered by 1.4.11 + 2.4.11 Minimum area clause).

I agree that the second part of the adjacent contrast clause seems to enable sites to pass 2.4.11 but fail 1.4.11 by not enforcing minimum adjacent contrast. I can understand the rationale of a site wanting to use an element size change (no colour change) to indicate keyboard focus (e.g. bigger button) but I thought that would be problematic when there is only one instance of an element so no "normal-sized" version to compare to. It could be hard for the user to identify the current focus location if they don't see the regular-to-big transition.

[mraccess77]

@RavenAlly I've brought up this issue with comparison of focus to unfocused states before as well. Same issue when background and foreground colors are flipped and you only have two controls on screen because the web page is zoomed in. Which state is the focused state and which is the unfocused state? Still problematic but doesn't seem to be covered by this SC.

[alastc]

Wondering if the "adjacent contrast" clause is necessary at all, as I would have thought that this is already covered by non-text contrast SC, making this redundant.

Non-text contrast doesn't specify what the contrast is with, so it allows for low/no-contrast of the focus indicator with the component.

so would there be situations where a focus indicator nominally passes this adjacent contrast clause due to 2px thickness, but would nonetheless fail non-text contrast?

I don't think that's likely, but some adjustments to the understanding doc for non-text contrast would not go amiss.

What's the "thickness" of the whole control changing color

Very thick! It sounds odd, but it works (notwithstanding Jon's caveat above).

so in theory if a single pixel is showing, it counts as not being obscured? this may be a bit too lax/pointless?

Yes, and I know that sounds like the previous case with 2.4.7. We've discussed some sort of percentage, but there are too many variables in testing. It seemed like better that nothing.

[alastc]

The 3rd bullet aspect is coming back to the group under #1490

For the un-obscured aspect, we have several previous responses:

• 2.4.12 Focus Appearance (Enhanced): Unobscured #1304 (comment)
• Focus Appearance (Minimum) SC2.4.11 - the Obscured bullet allows components to be completely obscured! #1271 (comment)

Is anything left after those?

[alastc]

Response accepted by the group:

---

Wondering if the "adjacent contrast" clause is necessary at all, as I would have thought that this is already covered by non-text contrast SC, making this redundant.

Non-text contrast doesn't specify what the contrast is with, so it allows for low/no-contrast of the focus indicator with the component. This is now mentioned in the understanding doc.

Also, non-text contrast SC has no "escape clause" about 2px thickness - so would there be situations where a focus indicator nominally passes this adjacent contrast clause due to 2px thickness, but would nonetheless fail non-text contrast?

It could fail the adjacent contrast to the component by being that thick, and non-text-contrast still applies.

What's the "thickness" of the whole control changing color (provided it contrasts sufficiently with the non-focused control)?

That would be very thick, there is an example of that in fig 13.

"Unobscured: The item with focus is not entirely hidden by author-created content." so in theory if a single pixel is showing, it counts as not being obscured? this may be a bit too lax/pointless?

Indeed, it is not ideal, but it was the only way (we could find) to capture the sticky-footer scenario without introducing a lot of complexity. The AAA version does not have that exception.

[mraccess77]

My read is that adjacent contrast of the indicator is to the control - so if the indicator is a perimeter border then the adjacent contrast is to the control's adjacent pixels that are not part of the indicator (and not the background of the page). If the focus indicator were to be inset (and large enough but not > 2px) - then the adjacent colors used for measurement would be on both sides of the indicator.

[alastc]

@mraccess77 - for the new SC?

If so, adjacent contrast would be either the control or the background, whatever is adjacent, possibly both. In practice, for an outset indicator the measure will be the same as 'change' of contrast because it is going over the background and is adjacent to the background.

If the indicator is inset, then change of contrast = adjacent contrast, so it needs to meet the contrast of 3:1 anyway.

[alastc]

The group accepted the response above.