Unclear situation in SC 1.4.11 Non-text Contrast where SC 1.4.1 Use of Color doesn't seem to apply

[OwenEdwards]

In the Understanding SC 1.4.11: Non-text Contrast document, there are some great examples of how non-text contrast affects users and some references to how a control could fail "Use of Color" instead of "Non-text Contrast."

I have a specific situation where I'm not clear whether a feature passes or fails 1.4.11 and 1.4.1, despite reading the WCAG 2.2 Recommendation and the two Understanding documents in detail.

The progress bar in a video player has a clear indicator of the current playback position in the timeline, but it also has a secondary visual indication of how much of the video has loaded (that change is in the red highlight box on the left - the end of the change is in the highlight box on the right):

The contrast of the loaded indication against its background meets the 1.4.11 requirement (3.8:1, as shown in the screenshot), but the change of the progress bar from its default color/shade to the loaded color/shade does not meet the requirement (1.9:1).

Figures 6 and 7 in the Understanding SC 1.4.11: Non-text Contrast document are relevant, and the text around Figure 15 is especially relevant:

Note that this Success Criterion does not directly compare the focused and unfocused states of a control - if the focus state relies on a change of color (e.g., changing only the background color of a button), this Success Criterion does not define any requirement for the difference in contrast between the two states.

[...]
Figure 15 The change of background within the component is not in scope of non-text contrast. However, this would not pass Use of color.

This isn't a focus state, and conveys actual information; but it doesn't use color (hue) to indicate information, it only uses a lightness change, and it's that change which is less than 3:1. Does this fail 1.4.11?

[TestPartners]

It is definitely a non-text contrast issue and yes, it fails (in my opinion). It's not a "Use of colour" issue because the meaning of each section of the slider is determined by its relative position, not its colour. The section on the left represents the amount of the video that has played. The section in the middle represents the amount that has downloaded, and the section on the right represents the amount that has not yet been downloaded. As long as there is sufficient contrast between each section, you can perceive the information.

Three colours can all have a contrast ratio of more than 3:1 with each other, but the colour palette is greatly reduced. There is a useful tool for experimenting at https://contrast-triangle.com/, albeit it's a rather clunky implementation. It would be nice if TPGi created a 3-colour version of their Colour Contrast Analyser.

The colour palette constraint could be eliminated by using a change of shape. For instance, the round slider handle already does this for the boundary between the left-hand and middle sections of the slider. This means you do not need a 3:1 contrast ratio between those two sections.

The middle and right-hand sections could be differentiated by their thickness, which would avoid the need for a 3:1 colour contrast difference.

Four colours cannot all have a contrast ratio of more than 3:1 with each other. If you agree with my view that all three sections of the slider need to have a contrast ratio of 3:1 with the background colour, then the sections MUST be differentiated by shape or something other than colour. Perhaps the right-hand section could be a dashed line in the same colour as the middle section, so there are only three colours.

[detlevhfischer]

In all cases where the video loads faster than needed for smooth playing, this "already loaded" information boarders on being irrelevant (admittedly there will be cases where it matters). In other cases where loading is too slow, the video pauses. Is there enough in it to call out a hard fail of 1.4.11? I agree though that technically , it is a fail.

[TestPartners]

It's still worth discussing because the same principle applies in other cases where a slider has multiple sections.

[mraccess77]

FWIW I use the pre-loaded indicator to let me know if I can watch videos at 2x speed or fast forward 10 seconds. If you try to fast forward 10 seconds and there is no buffer then it makes an even worse loading experience. But while I agree it seems like a fail - it's not a barrier to access the video.

[OwenEdwards]

As far as whether it is important information, as @mraccess77 says, it isn't a barrier to access the video, but it falls into a kind of information I see often where the question becomes "if it isn't important for users then why is it displayed at all?" Isn't it as important for low-vision users as for those with typical vision?

But as @TestPartners points out, it's a broader principal; in fact, broader than just about sliders, it isn't clear from the Understanding SC 1.4.11: Non-text Contrast document for any control or indicator - if a control or indicator changes shade to indicate information, is it just the contrast with the background that must meet the 3:1 ratio, or the contrast with the other state?

For example, if a radio button just changed shade to indicate selection, if both unselected and selected states are at least 3:1 with the background, does that conform with 1.4.11? Figures 5, 6, and 7 in the Understanding 1.4.11 document are very close to this situation, but don't actually address it; Figure 15 does seem to have a change of shade without a significant change of hue, but says "Note that this Success Criterion does not directly compare the focused and unfocused states of a control." What if the middle button in Figure 15 was in a different state (pressed) rather than just focused? I think the Understanding document needs to clarify that.

[mraccess77]

In terms of comparing states - we would not compare focused and unfocused states - but we would need to compare adjacent states such as the selected state of a page tab to the not selected state of the neighboring page tab. Just like in the rating example with the stars - we need to compare the filled star state tot he non-filled star state because they are displayed adjacent.

[yatil]

In this case, one of the adjacent colors is the play track, so it would need to have 3:1 contrast against it, especially as that border carries meaning. I think one can argue if knowing the loading state is essential and if the video stopping is not indication enough that it hasn’t fully loaded. Adding an icon to the end of the loading bar might help with making clear what the layered on top loading bar does.

[OwenEdwards]

@mraccess77 :

Just like in the rating example with the stars - we need to compare the filled star state to the non-filled star state because they are displayed adjacent.

I don't think the star rating examples in Figures 6 and 7 of the Understanding document are at all clear about this.

Especially in Figure 7, in the top example, the contrast between yellow fill and white fill is described as "Fail: The first example fails the Use of color criterion due to relying on yellow and white hues." (Note that it doesn't say anything about the contrast between the yellow and the white.)

The lower example in Figure 7 is described as "Fail: [...] The second example fails the Non-text contrast criterion due to the yellow (#FFF000) to white contrast ratio of 1.2:1." This seems to be talking about "the yellow (#FFF000) to white contrast ratio of 1.2:1" of the yellow stars on the white background, not the contrast between the yellow stars and the white stars; and that's how most of the other examples in figures read - it's the contrast against the background or another adjacent color.

I think Figure 7 should be modified to this, to make the requirement clear:

In the middle example, the fill in the first two stars is gray (so there's no use of color), which has sufficient contrast against the adjacent black outline but not against the white fill in the other stars. Does the WCAG WG agree that the middle example in this figure is a failure of SC 1.4.11? Because the SC itself says "The visual presentation of [active UI components styled by the page author] have a contrast ratio of at least 3:1 against adjacent color(s)" (emphasis added), which seems to say that the middle example is not a failure because the gray and white fills are not adjacent.

[JAWS-test]

... that the middle example in this figure is a failure of SC 1.4.11?

no, because the colors are not adjacent. But it is a failure of 1.4.1 Use of Color

[mraccess77]

What's confusing, while the understanding says the stars fail SC 1.4.1 use of color - 1.4.1 talks about where color has meaning assigned to it. In some of the cases we are discussing, the meaning of the color is irrelevant - what is needed is to be able to distinguish between lightness. While I agree 1.4.1 allows contrast to meet the color requirements - it's not as clear that it can be used to also require 3:1 regardless of hue when color doesn't have meaning. But I agree for purposes of current WCAG it's the best we can do to make this distinction and to fail these situations where some aspect of perception of light makes communicates meaning but it's not in an adjacent pixel.

[OwenEdwards]

@mraccess77:

While I agree 1.4.1 allows contrast to meet the color requirements - it's not as clear that it can be used to also require 3:1 regardless of hue when color doesn't have meaning.

Exactly! Specifically, in Understanding SC 1.4.1: Use of Color (Level A), there's this note:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater. For example, a light green and a dark red differ both by color (hue) and by lightness, so they would pass if the contrast ratio is at least 3:1. [...]

So, if the color (hue) doesn't change but the lightness does, I don't think most people would realize that this would/could be covered by 1.4.1 Use of Color rather than 1.4.11 Non-text Contrast.

That's why I think Figures 5, 7, and 15 in Understanding SC 1.4.11: Non-text Contrast (Level AA) are confusing, because they get close to the situation in my gray-fill stars example but do not specifically clarify it.

I think both Understanding documents need adjusting, perhaps using the gray-fill stars example, to clarify whether that situation is a failure of 1.4.1, and if it isn't a failure of 1.4.11 then to explain why it is a failure of 1.4.1 given that there is no use of color in the example.

Many people, seeing a black-gray-white control, wouldn't even think to look at whether it fails an SC called "Use of Color," but they might well look at the "Non-text Contrast" SC, so it would make sense for that Understanding document to explain why this situation isn't covered by 1.4.11 (because the gray and white aren't adjacent) but is covered by 1.4.1 even though there is no use of color.

[OwenEdwards]

@JAWS-test is the part of Understanding SC 1.4.1: Use of Color (Level A) that I quoted in my previous comment the reason why you say "it is a failure of 1.4.1 Use of Color"? Even though there isn't a difference in hue between the white and the gray fill (specifically hsl(0, 0%, 69%) vs hsl(0, 0%, 100%))?

[JAWS-test]

@OwenEdwards The reason is that in WCAG 2.0, when SC 1.4.1 was formulated, no distinction was made between hue, brightness and saturation, but color was the generic term for all 3 properties. At least that's how I understand https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html