Does the adjacent color clause of SC 1.4.11 apply when focus changes swap colors but also are adjacent to the background ? #1775
Comments
|
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. |
|
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. |
|
@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? |
|
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. |
|
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 |
|
@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? |
|
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 |
|
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. |
|
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... |
|
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 |
|
From the understanding doc: |
|
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... |
|
I agree both of Jon's examples fail. |
|
The odd threading we had to do with 1.4.11 was differentiating the more decorative 'states' like hover, from focus and things like selected for radio buttons. My recollection is that we determined that we could cover things like 'selected' if focus was only covered if it is compared to adjacent colours from the component. The last example in the table covers that, "Checkbox - Subtle focus style - fail" The example in the original post of this thread makes that harder to determine because the buttons only have 'content', (the icons) with no boundary/background of their own. Therefore for those icons:
For the 'test' buttons above, I agree they suck, but I don't think they are covered by 1.4.11. That's one of the reasons for the adjacent-bullet in the new SC: "The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component" |
how so? i don't see anything in 1.4.11 that would explicitly exclude this scenario - the darker blue and lighter blue inside the button need to be visually perceivable for a user to understand the state of the control (that it has focus). otherwise they'll just perceive it as having a solid blue background, which is the same as its unfocused state. sounds very much in line with
(from https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#user-interface-components) this is different from, say, the second selected radio button example (https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#figure-three-radios), where even if the user can't perceive the difference between the filled-in inside circle and the outer ring, and just perceives it as a single solid dark circle, it's still visually different from the non-filled circle when it's not selected (so there it's not necessary to distinguish the two, as they're not visual information necessary to indicate state) |
|
no, that's irrelevant, because i'm not saying "compare the unfocused test to the focused test and calculate the contrast based between them". i'm saying in this case, the internal darker blue in that button doesn't have sufficient contrast against the lighter blue of that same button. so the colours here are adjacent (rather than comparing two states that are not on screen at the same time and adjacent) |
|
Original test button - the focus indicator in this case fails 1.4.11 because it needs to be perceivable but lacks sufficient contrast
If it was like this (slightly hacked together) case, where the whole of the background of the button changes, then yes that would be the case where 1.4.11 does not apply (which is what #1058 addressed) as there's nothing "adjacent" that fails (but it will still fail 1.4.1 Use of Color in this case, because the focus indicator relies on color alone and the difference between the unfocused and focused background colour, which for 1.4.1 do NOT need to be "adjacent", is < 3:1)
|
|
It was my understanding that color swaps like |
not in 1.4.11, but why not in 1.4.1? |
|
2.4.11 is necessary because currently, even with 1.4.1 and 1.4.11 and the different situations they apply to, WCAG says nothing about how big/ "visible" a focus indication must be. in theory, a single 1x1 pixel contrasty indicator of focus passes focus visible and 1.4.11. 2.4.11 would patch THIS hole |
|
Just to weigh in here on the current situation with WCAG 2.1 (and sorry if this point has already been made). I find it confusing that the Understanding document for 1.4.1 Use of Color currently notes a requirement of a 3:1 contrast ratio as visual distinction (e.g. for a focus state versus at-rest state, where only a subtle change in the lightness of background colour would fail) yet technique C15, "Using CSS to change the presentation of a user interface component when it receives focus", is only an advisory and not required for conformance. Edit: Sorry – also realised there may be a better issue under which to make this comment. |
|
Ok - so if SC 1.4.1 applies - then it should apply to both situations both the full color swap and also the swap of an inset rectangle as well. in SC 2.4.11 editor's draft we have "Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states." - is that still needed if covered by SC 1.4.1? |
|
when discussing 1.4.1 (need to find the reference, eluding me at the moment), we came to the conclusion that to take it to the extreme, anything that appears/disappears on a page can be counted as a "change of color" and we could end up failing everything under 1.4.1 - which is obviously pointless. so if an existing shape/thing changes color, then we consider it for 1.4.1. if it's a case like your circle background in the first example, or even the inset extra border in your second example, that "thing" wasn't there before, so 1.4.1 does not apply. |
|
@patrickhlauke with that reasoning of it not being there before would mean the full background swap on the button would then not be covered by SC 1.4.1 either - unless the two items were adjacent to each other like page tabs and then SC 1.4.11 could apply as well. |
|
well, if you're treating the test button there in its unfocused state not as a "blue button with a gray/black border on a blue background", but rather "an empty see-through button with no background and just a gray/black border on a blue background", sure. but this is now splitting hairs even more than i normally do... |
|
(randomly, did i ever mention that 1.4.1 Use of Color is also a magnificently wooly SC because it can be (mis)interpreted in so many different ways?) |
|
the above assumed you meant if the test button itself was on a blue background. but just this image, where they are on a white background
clearly the unfocused button does have a background (it's light blue). its focused state changes the background of the button (to dark blue). the difference in contrast between those two is < 3:1. 1.4.1 does not stipulate the colors need to be "adjacent", but talks about the change in color, and that if the difference is < 3:1, it's only treated as a change of color (hue), not brightness, which would be a secondary visual characteristic (and therefore not just a change of color alone) |
|
As I understand it the inset focus ring or indicator would be failed by 2.4.11 under the comparison to focused and non-focused states as well as in regards to adjacent colors. @alastc explained that 1.4.11 deals with adjacent background colors while SC 2.4.11 deals with internal component colors - or at least that's what I understand from him. |
which seems to me where the bone of contention is ... as in my (and many other people's) reading of 1.4.11, it makes no difference if something is internal or external to a component ... if it's necessary to distinguish "the thing" for it to make visual sense to a user/make sure they can perceive it, and if they didn't manage to perceive it (be it an internal border, or extra circle, or whatever) they'd miss out on important information about the component or its state, then it would fail. |
|
Hi totally agree @patrickhlauke. |
|
randomly, as this issue has bubbled back into our consciousness ... it may also be interesting to note this sentence (just above Figure 4) https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
focus is a state. and this sentence essentially states that in cases where the visual info is required to identify the state, it makes no difference whether it's "outside" of the component, or it's comparing adjacent colours inside the component itself. |
+1 I have never agreed with this interpretation
Precisely. At the end of the day, what is the impact on the end user? It should not matter (I will argue) how (or perhaps more precisely "where") the change of state is visually conveyed, that conveyance MUST have sufficient visual contrast to meet the needs of the user.
I've always felt this is something of a cop-out, where we've relaxed the 'burden' on the author by shifting it back onto the user. I disagree with that approach. What is "too many"? If, instead of "16" that number was 12 - would that be fewer than "too many"? What about 10? 8? 4? As Patrick notes, focus is a state, and our current normative definition of state says: State: dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse. I will note that there is no distinction in our current definition on whether the visual change of state is "inside" or "outside" of the component, nor whether some states are 'different' than others: hover is far more 'temporary' than, say 'visited', but at the end of the day, if the page author chooses to use color to differentiate a change of state, 'temporary' or otherwise, then sufficient contrast MUST be conveyed. |
I'd grant that hover is slightly weird/has extra nuance. If there's visual styling to just indicate "yes, you're hovering this control", and if was already clear that the thing was a control (i.e. it's not through hover that the control is indeed "revealed"), then even if the indication had relatively low contrast, arguably a user can still see their mouse pointer and know that they're over the control/thing. If however on hover the whole component becomes unreadable/unrecognisable due to too low contrast, that will indeed be a problem in my book. so it comes back down to...context, as ever. nuance, the enemy of simple clear-cut rules... |
|
+1 Patrick, although I also note that hover (onHover) is essentially just a variant of focus (onFocus), and in fact I would expect that a site or page would have both (else that's a failure of a different sort I suspect). Nonetheless, I continue to advocate for the interpretation that any visual indication of a change of state MUST also meet color contrast requirements - and I fundamentally reject the argument that there are too many states that you would need to contrast with each other. (There may be 16 or more possible combinations, but I'd be extremely surprised to see a site using ALL of those potential 16 combinations) |
if a site applied a super subtle change of, say, background colour on a link, which barely contrasts at all against the page background, on hover, i'd not fail it because it's a bit of eye candy (for those that can perceive it) and nothing is lost for users even if that change wasn't there. obviously, if they did the same for focus, that would be a failure in my book as a keyboard user needs to know where their focus is (a mouse user knows where they are because...they have a mouse pointer). [all other things being equal, as said...if instead it was more "everything looks like static text, and only by hovering over stuff and observing any change in presentation do you understand that something is actionable/clickable, then yes i would fail for low contrast, assuming mouse cursor doesn't change either and the subtle change in background is indeed the only visual cue ... in that case, it's essential to be able to perceive that change, and it therefore must meet minimum 3:1 ratio). |
|
Update from the meeting today: https://www.w3.org/2021/06/29-ag-minutes.html#item06 Summary: The internal adjacency aspect could be read either way (to component or to indicator), but applying it inside the component creates other problems for states such as hover/visited etc. It would add quite a lot of new things that would fail 1.4.11. Not necessarily focus, but other states. Several people will get together to review the 1.4.11 understanding doc to clarify this. |
|
i thoroughly disagree with this decision, if it means that cases like
and
(whether the second state is one of focus, or in the case of toggles, when that second state is the pressed/selected state, etc) are then considered to PASS 1.4.11. ridiculous. those are different states, and sighted users need to be able to perceive the difference in state. it's essential for their understanding of the component. with contrast being so low, they won't. so a user may not know if that button/toggle is focused, or pressed, or whatever. visited and hovered are different, as they're usually "nice to have but not essential". |
|
and, as previously noted, 1.4.11's understanding already mentioned internal background in places like
so talking of "historical" interpretation, as if this idea of internal background was somehow new and introducing excessive new burdens, seems odd. |
|
actual live examples here https://codepen.io/patrickhlauke/pen/ZEKYYRe (showing two variations of focus indicator that's "inside" the component, and one case where an element "inside" the component is used to denote a toggle that's on/off). is the rest of the group saying that these are all kosher under 1.4.11? |
|
And if that style were used on hover, should that trigger a a failure as well? You can't decide to "not fail it because it's a bit of eye candy" in one case but not the other. |
|
it's eye candy on hover because you know where your mouse pointer is... a user doesn't need the hover to be able to tell where their pointer is. compare to focus where the indication is essential, otherwise the user won't know where their focus is (if nothing else is there) |
|
IF the element only reveals its actionable nature on hover, then it's not just eye candy, and then yes it would fail then as well if that was the only information provided to a sighted user that the thing they're over is actionable (if it didn't look like a button at all to start with, and reveals its button-like nature only on hover). then it's "required to identify user interface components" |
|
also, what people seem to be objecting to here is the "inside the component" aspect. are you now also arguing that you would not consider hover at all as a state, even if outside? or is the fact that it's inside the component giving you an out to now question other states like hover? |
|
in any case, i'd be very interested in folks looking at https://codepen.io/patrickhlauke/pen/ZEKYYRe and seriously suggesting all those are cases where 1.4.11 should not apply and it's all fine according to WCAG, because in my own testing these are all cases that i have already (historically) failed. |
|
added a hover example to https://codepen.io/patrickhlauke/pen/ZEKYYRe as well, a case where yes it would fail because it's essential to see the hover styling. again, it comes down to a fairly simple question to decide if something's eye-candy or not: if that particular thing wasn't there at all, would a user still understand the content/state? if not, it's essential, and if that then has too low adjacent contrast (whether it's inside or outside) and can't be distinguished/seen, it's a fail. |
you can decide if it is or isn't eye candy by asking "if this wasn't there, would the user still understand what's going on?" to then determine if it's "required to identify user interface components and states" |
could i request to be part of that group of several people please? assuming it's possible to work asynchronously on it |
|
I'd like to see these as failures as well - but I wanted the group to address the fact that the documentation had said something else. Some sort of acknowledgement of the change in understanding. One option was to make this change clear for 1.4.11 in WCAG 2.2. I agree the toggle switch example in the understanding document makes it clear that internal adjacent colors can and need to be included. |
It seems to me that not knowing whether something is an interactive element without hovering over it would be a general usability problem. If anywhere, it would belong to some future 'affordance' SC that so far has not seen sufficient support or testing feasibility to make it into a draft. I think of the examles in the @patrickhlauke's codepan, 1-5 clearly fail 1.4.11: The indication of state (whether focus or activation) is compared to the adjacent color and found insufficient. If there is something in the 1.4.11 Understanding text that could be interpreted as making internal state indicators exempt, it should be removed. In terms of focus, example 6 seems more like a general usability problem - it depends on the context whether the element would be perceived as an interace component (It probably would be if the element was on a map and there would be a text above saying "You can toggle map view and satellite view"). It would still fail 1.4.11 for lack of contrast in terms of activation state. |
|
Hi Folks, another update from the call, where this update in #2028 was approved. I think that closes this issue, but I'll leave it open for a few days in case anyone on this thread would like to chip in. |
|
#2028 tackles the focus aspect, but as mentioned, I think the same rationale/discussion also applies (in combination with use of color) to other states like pressed. may open a separate discussion on that wider topic... |
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?
The text was updated successfully, but these errors were encountered: