Color contrast SCs still insufficient for LV and users with color deficiencies

[karlgroves]

Looking for an official WG statement of interpretation on the following concern:

Any given UI control can undergo a variety of state changes based on things like system state or user interaction. Perusing past issues and mailing list archives, I'm unsure what the official word is on the differences between states.

For instance:

1. We know that the inactive/ default state of a link should have sufficient contrast against its background. (1.4.3/ 1.4.6)
2. We know that the focused/ hovered state of the link should have sufficient contrast against its background (1.4.3/ 1.4.6)
3. We know that the focus state of the link should have a visible difference of some kind (2.4.7)

If we change only the color of the link's text or background we can meet all 3 of the above, but still offer a bad experience users who are LV or color-blind.

Consider the following:

#navbar li a{
   color: #eee;
   background-color: #333;
}

#navbar li a:hover, #navbar li a:focus{
    color: #eee;
    background-color: #000;
    outline: none;
}

In the above sample, we see a case where the background color changes from a very dark grey to black.

Some might say that removing the default focus indicator is why this would fail, but the only thing that's required is that it be "visible", which is not defined in any normative content.

Another argument would be that the difference between #333 and #000 is too subtle for 2.4.7. We could bump that up to #555, which is far more obvious, and still have bad contrast between the two states.

Unfortunately, existing contrast SCs 1.4.3 and 1.4.6 and the new 1.4.11 don't discuss this type of scenario in any meaningful way.

[alastc]

(non-official comment/questions)

Yep, the tricky aspect is the design implications for applying contrast to one component in a variety of states.

For example, an input can be active/focused/hovered/selected, at the same time, there's a lot of combinations.

A worry is that if we go down the route of saying that each state must contrast with the other states and agaisnt it's adjacent colour, we don't have enough contrasting colours.

The new 1.4.11 does explicitely bring in the states of interface components, but I'm certainly open to any ideas on bringing in some kind of matrix of requirements for assesssing contrast across states... so long as it's reasonably testable!

[awkawk]

(Official WG response)
Thank you for your comment. The working group appreciates that the changes between states should be obvious to people viewing the content. However, it is very difficult to craft a requirement that does not run into the issue of not having enough colours for a particular component. The focus of this success criteria is to cover the non-text parts of (active) UI components, but we will certainly consider expanding to explicitly cover the differentiation of states for UI components in future iterations.