2.4.11: Focus Appearance - Clarification with 1.4.11 Understanding Non-Text Contrast relationship

My reading of the 2.4.11: Focus Appearance "Relation to non-text color contrast" section is the following...

1.4.11 Understanding Non-Text Contrast requires that custom focus states pass contrast with adjacent colours.

You are not comparing the unfocused state with the focused state. But when the element is in the focused state, you need to check that it passes contrast with adjacent colours. Unless it is native.

This success criterion does not care whether the contrast difference between the two states is poor. You are only ever testing adjacent colours that can be accessed at any one single point in time.

2.4.11: Focus Appearance requires that the difference between focus states (native or custom) pass contrast. That is my reading of the "Relation to non-text color contrast" section.

It otherwise needs to be a certain size and not be obscured.

However, the following part of the normative definition implies that the relationship has more nuance.

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 has a thickness of at least 2 CSS pixels.

In some cases, it does involve testing adjacent colours.

I think I understand it, along with the other conditions of the new SC. But it would be nice to have this specific point explained in simple terms in the "Relation to non-text color contrast" section. How do the adjacent colour checks differ between SC?

For example, an interesting point is "The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent colors (including the component)", which I don't think is in scope for 1.4.11.

[alastc]

How do the adjacent colour checks differ between SC?

For Non-text contrast, it matters whether the control has contrast with it's adjacent colours, but if the focus indicator contrasts with something, that may not be enough to make it reasonably visible.

It is something that was intended to be addressed in 2.1, but it turns out that one adjacent colour is not sufficient for visibility, and both adjacent colours is very difficult to implement usefully. An SC specifically for the dynamic aspect (focused vs unfocused) was needed.

So the answer is essentially: In non-text contrast the component should not lose contrast when focused. In focus-appearance the focus indicator has more specific rules to meet.

That is essentially what the first two paragraphs of Relation to non-text color contrast say, so if you have any suggestions to improve that they would be welcome.

[mraccess77]

@alastc For orgs that do not adopt WCAG 2.2 we need to maintain the requirement of focused state indicator with adjacent colors in WCAG 2.1 SC 1.4.11. From what I understand it's only adjacent colors on one side and as you say it is primarily focused on the component as a whole in that state and as discussed does not touch comparing focused and non-focused states. I just want to remind the group to not remove too much from the understanding doc for folks who do not adopt WCAG 2.2 yet.

[alastc]

@mraccess77 - agree, and we've separated the 2.1 and 2.2 docs now, so we can pick and choose which updates go into 2.1.

[alastc]

@wardav there is a similar issue that came out of a group discussion in #1490, with a proposal there as well.

[alastc]

HI @wardav,

The understanding doc now includes this in the 'relationship to non-text contrast' section:

Non-text Contrast does not require contrast between the UI component's focused and non-focused states, merely that in each state it contrasts against the adjacent background.

Focus Appearance (Minimum) requires that the focused and unfocused states can be distinguishable from each other. It does this by requiring sufficient differences in contrast between the appearance of a component when focused and when not focused.

Does that resolve this issue for you?

Yes, thank you.