Does the adjacent color clause of SC 1.4.11 apply when focus changes swap colors but also are adjacent to the background ?

[mraccess77]

I originally wrote this as a discussion question 21 days ago in this github repository but it has gotten no attention. So I'm posting here as an issue.

In the screenshot below the button background and page background are the same color. The focus indicator is communicated by a color change of the circular button to become darker. SC 1.4.11 doesn't require the focused and unfocused states to have contrast - but must the new focused color contrast with adjacent page background colors as well because the focus indicator takes up the whole button area?

For a circular button - what is considered the component rather than page background - is it the bounding box or the visible component?

[patrickhlauke]

if i can't see/perceive the darker circle against the overall page background, I can't perceive the focus state. so to me yes the dark circle must contrast with 3:1 against the background. yes, we did say previously that we can't simply compare "focused state vs uncofused state", but the individual states themselves, when in effect, also still need to pass adjacent colour criterion for the bit that matters...which in this case, is the focus indicator.

[patrickhlauke]

the bone of contention in the past was that you can't compare "focused vs unfocused" because unless you have both focused and unfocused components butting up right against each other, there's no "adjacent" colours to compare things to.

[mraccess77]

@patrickhlauke I'm not suggesting we compared the focused and unfocused states - but asking if we need to compare the focused states colors to the adjacent background for this situation. Previously @alastc had said that an inset indicator that swapped colors would not be covered by SC 1.4.11 - but in this case it's not simply inset. Would it make a difference if the circle got larger when focused?

[patrickhlauke]

in the case you're showing in your screenshot, no, it wouldn't make a difference if the dark circle got larger (larger than what? the unfocused state has no circle?)

there's no "inset" here, as there's no visible outer boundary (when not focused). or am i missing something?

i.e. purely visually, there's no circle to start with. and when it receives focus, there's a dark blue circle that appears behind the icon to indicate it's focused. and that dark blue circle is necessary to understand the state of that control (that it is currently focused), so it needs to have sufficient contrast to any adjacent colours (the page background) for that to happen.

[patrickhlauke]

randomly, if somebody tried a "ah, but even when not focused, there's a blue circle already there, it's just that it happens to be the same colour as the background so you can't see it" smart-alec argument here, i'd say fine, this then fails 1.4.1 use of color, since you're changing this "preexisting circle" that isn't actually visible from blue to dark blue only...and the difference is less than 3:1

so either way you want to slice it, that dark circle needs to have a contrast of 3:1 or better against the blue colour of the background / the blue colour of the theoretically already there, but just not visible, circle

[mraccess77]

@patrickhlauke I think this should fail because the swapped colors touch the adjacent page background - and I think it sounds like you agree - but I wanted to get others take on this because I'm not sure that's how others read it. I may have mis-read your 2nd comment when I replied above.

Do you agree with interpretation in the understanding that if the control had an inset indicator that swapped colors but did not reach the border then it would not be covered under SC 1.4.11?
Screenshot with inset focus indicator that never touches background colors of page and thus is not covered by SC 1.4.11

[patrickhlauke]

to clarify: your original example to me fails 1.4.11

now, your new example here to me also fails 1.411, as regardless of whether it's inset or not, that focus indicator of slightly darker blue still touches light blue adjacent colour, and has a ratio below 3:1, and being able to perceive the difference between the light and dark adjacent blues there is essential to understanding the state of the control.

if the whole "Test" button when focused changed just to that slightly darker blue, I'd pass this for 1.4.11 (as there would be no adjacent areas of dark blue touching light blue), but fail under 1.4.1 because it just uses a change of color to indicate focus

[mraccess77]

Thanks @patrickhlauke - as a group we absolutely need to agree on these things as they come up almost daily and I've gotten different responses from the leaders in the Accessibility Guidelines working group.

[patrickhlauke]

FWIW i don't currently see anything in the understanding document that would contradict our take here (that both examples you provide fail 1.4.11). the different answers from people may be down to just talking theoretically about "what if it has an inset extra border" or some such, which may conjure up different mental images for different people? not sure...

[patrickhlauke]

the one example that could possibly cause confusion about inset background colour etc is the second radio button here in https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

in that second example, true the inside dark gray doesn't contrast enough against the lighter gray circle of the radio button, but it's not essential for the visual understanding here to see the contrast/differentiation between the original outer circle and the filled inside ... just that visually, this changed from an empty circle to a filled circle - so even if a sighted user perceives the second selected radio button like a solid one indistinguishable from the third radio button (where the fill is the exact same as the outer circle, so seamless), they can still visually perceive the state of selectedness that is different from the unselected first radio button.

to me, some of this hinges on a "if there was no contrast at all between these two colours that i'm not sure about, would a sighted user still be able to understand what's going on" every so slightly subjective take

[mraccess77]

From the understanding doc:
In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused, except where the appearance of the component is determined by the user agent and not modified by the author.

[patrickhlauke]

ok, so i'm not seeing how that sentence would provide any doubt about whether your two examples would fail (unless there's some over-reading of what "adjacent background" is intended - to me that means "adjacent to the focus indicator" - not "adjacent to the component itself - so regardless of whether it's inside or outside of the component itself)

to put another way, only a weird reading of "we need to treat the component as an atomic entity, and can't take into consideration anything that happens inside it" would lead one to say that because of that sentence, both your examples don't fail. which would be quite obtuse, in my mind...

[detlevhfischer]

I agree both of Jon's examples fail.