Does SC 1.4.11 require comparing focused and non-focused states

[mraccess77]

I'd be interested in getting an official opinion on comparing focused and non-focused states. While I agree these may be issues for the user -- I think this could be hard to test as there could be inversion of colors, etc. and the area of the change may be larger than just a line -- such as changes in the background. I do see this issue come up a lot and it's a real issue for users -- but I'm not sure what the intention of the group was to cover it.

An example I commonly see is a control with a darkish background and light text and when the control is focused the background becomes darker. It's a subtle change that is hard to detect for people with limited contrast sensitivity.

[patrickhlauke]

this seems a follow-up to #517 ?

my take would be that by the literal definition in the normative text, the answer is no, unless there are two elements - one focused and one non-focused - right next to each other, to satisfy the "adjacent colors" part of the normative text.

if you meant the question as, essentially, "can we use 1.4.11 to determine if - assuming color is the only thing that changes between focused and unfocused states - the contrast difference between the focused and unfocused color state is sufficiently high to be distinguishable", then i'd say no.

[alastc]

By the text of 1.4.11 I'd say that the component needs to have contrast in whatever state, but then in combination with Focus-Visible the focus state also needs to be clear (compared to it's non-focus state), and contrast can be a method for that.

I think this is best dealt with by a positive technique or two, and I've had some conversations with gov.uk folk, the outcome of which was a good idea for a technique. Some of the things @mbgower has talked about probably also contributed to this.

I have in mind a technique aimed at defining a pass with CSS outline, which is tricky when talking about 'adjacent colours'. Briefly (as I should be doing client work right now):

Title: Using a contrasting outline to change a compents shape.

Desc: Adding an outline which contrasts against the component's background (rather than the component) changes the components shape. For example, if you have a dark blue button on a white background, the outline would need to contrast against the background colour, not the component colour.

This builds on the concept that it isn't about hue, it's about luminance, so in a grayscale sense it is changing the shape of the component rather than relying on colour.

The other way to think about it is that when you add an outline of some kind, what colour is it replacing? If you replace white with a dark colour, that provides a better indicator than a pale yellow, or subtle grey shadow.

[patrickhlauke]

but then in combination with Focus-Visible the focus state also needs to be clear (compared to it's non-focus state)

but then we're back to #302 which doesn't define what "visible" means...and we have nothing that normatively defines this, still (as 1.4.11 doesn't explicitly address this, and we're back to personal interpretation beyond the normative wording of the SCs)

[patrickhlauke]

to expand my previous: 1.4.11 defines that the focus indication itself needs to satisfy the contrast requirement...in isolation. as long as the focus indication has sufficient contrast, it would pass 1.4.11. but nothing says how distinguishable focus indication needs to be, normatively, from non-focused state.

for instance, i could have a control that has a border of #666 against #FFF, and when focused its border changes to #665. in both cases, both color values for the borders amply pass 1.4.11, and nominally this passes focus visible (as there is a "visible" change between #666 and #665). and nothing normatively anywhere says otherwise?

[detlevhfischer]

This does not feel right. If colour is the only change on focus, I think (the interpretation of) the SC should require 3:1 between default and focus colour. If that’s hard to do, use a border, colour inversion, additional marker, whatever. If the normative text does not support this interpretation, it should be something for 2.2.

[mbgower]

As mentioned in the originating discussion back in #517 , we're (understandably) mixing two requirements here. Focus Visible has a requirement that the keyboard focus be visible.
Non-Text Contrast has a requirement that the visual information required to indicate states has a 3:1 contrast against adjacent colours.

The argument for not including the difference between focused and unfocused states in the 3:1 formula is the same one that was made (and agreed on in discussion; hopefully that is in the minutes) for all the other states -- that the measurement is against adjacent colours, not between states.

However, my argument (and my recollection of what we arrived at) is that one must perceive the difference between focused and unfocused state in order to meet 2.4.7 Focus Visible, so the two states must meet the minimum contrast requirements of 3:1. In other words, having established this minimum contrast for non-text contrast, I think it is both logical and consistent that "visible" in the sense of 2.4.7 must be a differentiation between the focused and non-focused states.
Otherwise, one could minutely alter the non-focused styling and say the focus is visible when the difference would be indiscernable. We already have a failure technique that more or less makes it clear this fails. See Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator What was always missing from 2.4.7 was some measuring stick for what constitutes "visible." We can now point to the 3:1 ratio in 1.4.11 to show what the measure for sufficiently visible is.

[patrickhlauke]

Arguably though, that is only an interpretation? And doesn’t redefining “visible” change the meaning/interpretation of the 2.0 SC, which 2.1 isn’t/wasn’t allowed to do?

…

On 3 Dec 2018, at 15:27, Mike Gower ***@***.***> wrote: As mentioned in the originating discussion back in #517 , we're (understandably) mixing two requirements here. Focus Visible has a requirement that the keyboard focus be visible. Non-Text Contrast has a requirement that the visual information required to indicate states has a 3:1 contrast against adjacent colours. The argument for not including the difference between focused and unfocused states in the 3:1 formula is the same one that was made (and agreed on in discussion; hopefully that is in the minutes) for all the other states -- that the measurement is against adjacent colours, not between states. However, my argument (and my recollection of what we arrived at) is that one must perceive the difference between focused and unfocused state in order to meet 2.4.7 Focus Visible, so the two states must meet the minimum contrast requirements of 3:1. In other words, having established this minimum contrast for non-text contrast, I think it is both logical and consistent that "visible" in the sense of 2.4.7 must be a differentiation between the focused and non-focused states. Otherwise, one could minutely alter the non-focused styling and say the focus is visible when the difference would be indiscernable. We already have a failure technique that more or less makes it clear this fails. See Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator What was always missing from 2.4.7 was some measuring stick for what constitutes "visible" We can now point to the 3:1 ratio in 1.4.11 to show what the measure for sufficiently visible is. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mbgower]

@detlevhfischer, if colour is the ONLY way the component differentiates its state, then we can fail it under Use of Color which states colour cannot be used as the only means of "distinguishing a visual element." We already have the precedent with link coloring (and a failure technique) that a 3:1 contrast ratio against non-linked text is sufficient to not be considered use of color. We then apply that same logic to the differentiation of states.

[mbgower]

@patrickhlauke , sure it's an interpretation. That is ultimately what we're being asked to make. If you look at the two failure techniques I cited, they are interpretations of 2.0. Failure techniques in particular provide clarification (and precedence) when trying to create consistent guidance out of the normative text.
In regard to redefining 'visible', I think we have introduced clarity with 1.4.11 that can be directly applied to inform the discussion of 2.4.7.
If we don't have agreement to make a failure technique, then I certainly think we can create a sufficient technique where focus state is distinguishable from non-focused by a differentiation of 3:1. That's not saying anything else is unacceptable. Merely that meeting 3:1 between the states is a way of meeting 2.4.7.

[alastc]

I think we've added to the concept of 'visible', rather than redefined it.

I put together a little test page of button focus styles, examples 4 & 5 are key to what I was saying about the technique.

• Example 4 does not have contrast between the component and the outline, but does change the shape of the component.
• Example 5 adds an outline that contrasts with the component, but not the page. As it doesn't contrast with the page, I'm saying that fails as it doesn't change the shape of the component.

[detlevhfischer]

@mbgower I don't think that '1.4.1 - Use of color' would cover this in all cases. A button that changes color when receiving focus is arguably different from inline links which are only differentiated from the text around it by color. A button would already, by its shape and position, "convey information, indicate an action, prompt a response, or distinguish a visual element" (to paraphrase 1.4.1). Would you fail a button with a background that gets a lot darker (> 3:1 compared to default) for not meeting 1.4.1? The noticeable contrast offset (rather than color change) Would IMO be a clear-enough focus indication. So I feel some threshold (like 3:1) for contrast-only changes used for focus indication is warranted. (and I agree with others above that this can be done via a positive technique, though I wouldn't mind a failure for those oh so subtle, minute color changes for buttons that you get with some frameworks).

[detlevhfischer]

@alastc Maybe add Example 11 (button where just bg color changes from light grey to mid grey -- offset contrast > 3:1)?

[patrickhlauke]

I think we've added to the concept of 'visible', rather than redefined it.

i'd say "restricted", rather than "added", though. as in with this interpretation, sites that previously passed the visible focus SC would now tend towards failing instead.

[mbgower]

@patrickhlauke I'm not going to lose any sleep if someone whose 'visible' focus is in fact pretty invisible needs to address the problem in 2.1 as a result of this clarity.

If they want to maintain their difficult-to-use design, and are comfortable with whatever definition they've devised for 'visible,' they can still claim to pass 2.0, but are arguably going to need to put in additional effort to meet 2.1 -- although even that is debatable if we don't have agreement to make a failure technique; remember one of the ideas being discussed here is just to make a sufficient technique. In such a scenario, we are not making a required technique, so that team can still come up with some technique they think constitutes 'visible' and trust to the strength of their argument when they are challenged about the site's crappy focus indicators by a client.

In the same way Reflow is going to augment our understanding and approach to Resize Text, Non-text Contrast is going to augment our understanding and approach to Focus Visible.

I get the point you're making, but if we have a sufficient technique called "Making Focus Visible using an indicator that achieves a 3:1 contrast in comparison to a non-focused state" (or something less wordy), and have it be sufficient for 1.4.11 and 2.4.7, I don't see us crossing a line.

[johnfoliot]

+1 to Mike Gower JF

[jake-abma]

Just another comment on what is in the main comment: @mraccess77 says:

I think this could be hard to test as there could be inversion of colors, etc.

But inversion is never part of testing, is it? (besides checking to see if all is still visible), as inversion can also be very different with different setting / OS and AT.

[alastc]

I think the current status is that: Inverting a color (e.g. white text blue background, to blue text white background) like figure 3 in the current understanding, is a method of showing a state such as focus.

From the updates in PR #550 that is more explicit, and we could probably create a failure of 1.4.1 for subtle changes of focus indicator (which rely on a color change-only that doesn't meet 3:1).

[jake-abma]

aha, exchange / swapping colors, not inverting, clear

[mbgower]

@alastc Just wondering where we're at with this one. Was the decision to make a Failure technique? Are we just going to make a sufficient technique along the lines of "Making Focus Visible using an indicator that achieves a 3:1 contrast in comparison to a non-focused state" (or something less wordy)? Has anyone drafted either or been assigned?

[alastc]

In #550 I think it's a lot clearer (preview), and I added a 'to do' technique to Focus visible about changing colours with contrast.

That says:

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.

I'm not 100% happy with that because there should be valid techniques where the contrast is with the component rather than the background adjacent to the component. Going back to the original example:

a control with a darkish background and light text and when the control is focused the background becomes darker. It's a subtle change that is hard to detect for people with limited contrast sensitivity.

It is clear that there is a good technique (to be written) about having a sufficient change of contrast, but we still have the issue (discussed on Tuesday) about what constitutes a component, and what constitutes author-changed that make it less clear it is a fail.

[patrickhlauke]

just to check then, this (re)definition here of the need for a 3:1 contrast ratio affects pass/fail for 2.4.7? i.e. if the contrast ratio between the focused and unfocused color is less than 3:1, where is the failure? in 2.4.7 or 1.4.11? and, if the former, was that not something we weren't allowed to do for WCAG 2.1?

[edit: ah, i see i asked similar before here, and the last was that this is not a "redefinition", but more about clarifying what "visible" means. nonetheless, i'd still say this is a narrowing of the definition regardless, so content that passed 2.4.7 previously in WCAG 2.0 would now fail if being reevaluated under 2.4.7 in WCAG 2.1, no?]

[alastc]

I'm kinda in wood-for-the-trees mode on this one now, but I think we have a basis for failing an author-created focus indicator (such as an outline) that does not contrast with the background adjacent to the component.

It is added to the component, it is the state of the component, and it's by the author.

The gap (not sure it's common, but still), is that no related SC really deals with changes in appearance. I.e. the difference between states that are shown by changing the colour of part of the component.
We deal with the states, but not the change, or the visibility of the change.

If a component maintaines contrast across states (which is paramount), a subtle change within the component to show a state is not covered. Like Jon's example at the top, a dark button going darker on focus.

The updates are better for making sure state indicators like checkboxes are clearly covered, but without over-reaching (e.g. hover/active etc) we cannot also fail focus styles that do have contrast, but are not clearly different from the default state (but do have some minimal, visible change).

We can and will provide a positive technique for focus visible. If this is a common problem we can create an SC realated to Focus Visible that defines 'visible' at last, and at the same time remove the exception about browser-based styles. (Which would also mean retiring G165 as a sufficient technique.)

[alastc]

Hi @mraccess77, is the original question answered now?

[mraccess77]

@alastc yes -- what I heard is comparing the focused and non-focused states is not covered. But the focused state itself including when the focus indicator is displayed over a background that has been set by the author then it applies because it is part of the UI component and not the default provided by the browser.

[alastc]

including when the focus indicator is displayed over a background that has been set by the author then it applies because it is part of the UI component and not the default provided by the browser.

I don't think that is covered, at least it's not agreed (the background aspect, JF was going to write something up). Focus visible is the SC that would be applying, and 'visible' needs some work. A change in contrast can be a method of meeting that, but I don't think we have SC text that fails on comparison of contrast between states, as contrast uses 'adjacent' colors.

I think that's a useful gap to fill in (a possible) 2.2, something that sets up 'visible' as a minimum requirement in comparison to the default state, and we can use all that work Jared & I did creating lots of different buttons!

[mraccess77]

@alastc I'm confused regarding the background bit as this isn't about comparison between states but simply making sure the focus indicator has sufficient contrast which is covered under this SC.

[alastc]

I just meant whether changing the backround qualifies as changing the component, I don't think that has been agreed, and if it were then we would have to agree to retire G165 as a sufficient technique for focus visible.

[mraccess77]

Ok. I think we can close this issue and if we need to open another we can.

[mraccess77]

As note - the Understanding document for SC 1.4.11 says the following
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.

Which is misleading to imply that either 2.4.7 or 1.4.11 requires this -- but neither do require it -- 2.4.11 will though as 2.4.7 doesn't have any formal contrast threshold.

[patrickhlauke]

@mraccess77 i filed #1058 to address this, as indeed that part of the understanding doc is simply incorrect in my view