WCAG 2.1 SC 1.4.11 - techniques are inconsistent/unclear

[maryjom]

I have a couple of issues with the techniques for SC 1.4.11 Non-text Contrast.

• The understanding document's list of techniques doesn't line up with what's listed in the How to Meet document. Example: How to meet has advisory technique G183, but it isn't listed in the Understanding document. I believe that G183 is clearly a technique for SC 1.4.1 Use of Color and not really for SC 1.4.11 so it shouldn't be listed in the advisory techniques.
• F78 is about not removing styling that causes the focus to become invisible. This is clearly a failure technique for SC 2.4.7 Focus Visible. If there are aspects of this failure technique that are specific to 1.4.11 (Non-text contrast) that aren't about making the focus visible then that should be carved out into a different failure technique. I worry about failure techniques that cause one to report failures on multiple SC for a single issue.

[JAWS-test]

G183: I agree, both documents should refer to the same failures and techniques. And G183 only belongs to SC 1.4.1.

F78:

is about not removing styling that causes the focus to become invisible

F78 is also about: "or rendered non-visible by other styling on the page". This also applies to SC 1.4.11 (examples 2 and 3 of F78).

I worry about failure techniques that cause one to report failures on multiple SC for a single issue.

That's what many failures do: F13, F20, F24, F30, F33, F34, F40, F41, F42, F55, F67, F74, F83, F89

For F78, one could also argue that Example 1 is a violation of SC 2.4.7 (no focus) and Examples 2 and 3 are a violation of SC 1.4.11 (focus does not have sufficient contrasts). This would at least be the case in example 2 and 3 if the border and focus do not have the same color, but a similar one (with contrast below 3:1).

SC 1.4.11 is also about focus because SC concerns the "status" of interactive elements. Examples of the status are given: "... focus, hover, select, press, check, visited/unvisited, and expand/collapse". The Understanding provides the following explanations in this regard: "Also, any visual information necessary to indicate state, such as whether a component is selected or focused must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio. ... Using a change of contrast for focus and other states is a technique to differentiate the states. This is the basis for G195: Using an author-supplied, highly visible focus indicator, and more techniques are being added. 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. If the focus state relies on a change of color (e.g., changing only the background color of a button), then changing from one color to another that has at least a 3:1 contrast ratio with the previous state of the control is a method for meeting the Focus visible criteria."

Of course, it would be nice if the heading of F78 also names 1.4.11, as is the case with other failures that violate several SCs.

[mraccess77]

Hi @maryjom SC 1.4.11 does cover the identification of the control both in focused and hover state -- but not the comparison between focused and non focused and not the comparison between hovered and non-hovered and so forth. For example, if I tab to a control and now the control has insufficient contrast to identify it then that's an issue for low vision users. When you are working in a magnified view you may only have one or a small number of interactive controls in that view and so when you tab to or hover something you still need to be able to identify the control.

[JAWS-test]

Hi @mraccess77

SC 1.4.11 does ... not [cover] the comparison between focused and non focused ... state

if I understand SC 1.4.11 correctly, your statement is incorrect. SC 1.4.11 also requires that the status of interactive elements be recognizable, not just the element itself in different states. This means that if the element has a focus outline, it must have sufficient contrast to the background. If the focus is represented by a different background color and this background color borders directly on unfocused elements, then the two background colors must have sufficient contrasts. The only question is what happens if the background colors are not adjacent:

• either it is a violation of SC 1.4.1, if the contrasts are not sufficient (as discussed in https://github.com/w3c/wcag/issues/875)
• or it's a violation of SC 1.4.11. (as described in G195: "As focus moves, the currently focused menu item changes its background to a different color, which has a 3:1 contrast ratio with the surrouding items and a 4.5:1 contrast ratio with its own text". Note that the word "surrounding" is used here, not "adjecant". I don't speak English, but I suspect that "surrounding" has a different meaning than "adjecant". I think "surrounding" means all elements in the vicinity that belong to the same type (here: all menu items) but don't have to be immediately adjacent.)

I think you're right for hover because there is currently no requirement for hover in WCAG. So I made a suggestion for hover: https://github.com/w3c/wcag/issues/899. The discussion about the difference between focus and hover has already been done in https://github.com/w3c/wcag/issues/896.

[alastc]

Hi @maryjom,

The understanding document's list of techniques doesn't line up with what's listed in the How to Meet document.

I think that is a syncing issue, there have been some updates to the techniques listed, but it's a manual process to transfer over the listing to the How to Meet doc. The understanding docs are the 'source of truth', so the How to Meet should sync with that at some point.

F78 is about not removing styling that causes the focus to become invisible. This is clearly a failure technique for SC 2.4.7 Focus Visible.

Originally that was intended to be covered, but as various examples came up and were worked through, applying to focus styles became untenable.

So whilst @JAWS-test's comment is sort of correct:

SC 1.4.11 also requires that the status of interactive elements be recognizable, not just the element itself in different states. This means that if the element has a focus outline, it must have sufficient contrast to the background.

We agreed that it was more important (and possible) for 'status' to apply to elements like arrows for drop-downs, rather than dynamic changes like focus indicators.

The problem is that you could have a focus outline like examples 2 & 3 in F78 that meet non-text contrast, because it does have sufficient contrast with the background around the component. But it doesn't meet F78 (for visible focus).

That's why we've better defined 'visible' in the proposed WCAG 2.2 criteria, separately from non-text contrast.

In the meantime, I'll remove F78 from non-text contrast in the bumper-update I'm doing.

[mraccess77]

In the image above we have 3 white icon buttons on dark blue background. There is a light blue circle around the white icon when focused.

• Non-focus contrast of background to white icon is 5.7:1
• Focus contrast of dark blue background to light blue circle is 1.81:1
• Focus contrast of light blue circle to white icon is 3.2:1 Does this pass since there is > 3:1 from the light blue circle to the white icon? I assume this is a pass because we are only looking at whether the control is still identifiable when focused and the white icon is. This SC doesn't address the issue of being able to differentiate which one is focused or not.

[patrickhlauke]

@mraccess77 not quite sure, as arguably being able to discern that light blue circle is "required to identify user interface components and states" (emphasis on "states") in this particular example. and that light blue circle has too low contrast (1.81:1) against the dark blue background to be discernible, meaning that the state can't be discerned. and in this case (compared to other situations where we said that we can't compare non-focused and focused because they're not adjacent) we are clearly comparing adjacent colors (light blue against dark blue).

long story short, i would say this fails 1.4.11

[JAWS-test]

@mraccess77 The Understanding of 1.4.11 explains that focus visibility is checked, so your example would be a violation of 1.4.11 (I fully agree with @patrickhlauke). Once WCAG 2.2 has been adopted (with the new SC 2.4.11) I would be in favour of no longer considering it as a violation of 1.4.11 so that the same problem does not violate different SCs. The explanation in 1.4.11 should then be adapted accordingly.

[jake-abma]

The way I have understood Alastair's explanation more than once is that the moment the focus appears, it IS the component / non-text content at that time (the complete icon + the focus circle), the change is the change in color from dark blue to light blue, and thus we have not enough contrast against adjacent color(s), resulting in a fail.

[mraccess77]

Thanks everyone for the responses on focus. I've heard different things from others who have spoken to @alastc. So it sounds like what you are saying is that what is communicated the focused state is where the light and dark blue touch and therefore that is the region to be considered as adjacent colors for the contrast testing.

[patrickhlauke]

the focused state is where the light and dark blue touch and therefore that is the region to be considered as adjacent colors for the contrast testing

the user needs to be able to discern the light blue, as that is what communicates the state ("required to identify user interface components and states", emphasis on states), so yes.

[alastc]

I've heard different things from others who have spoken to @alastc.

The contortions we've been through to apply a "simple" contrast metric to a dynamic state is why I've been so enthusiastic about adding to focus-visible.

Under 2.1 we've used the combination of focus-visible, non-text-contrast and color-alone to try and tackle focus styles, and I agree with the comments above. However, I'm looking forward to 2.2 being easier to explain!

[mraccess77]

FYI. The how to meet document still lists g183 as advisory for SC 1.4.11.