WebAIM - Web Accessibility In Mind

E-mail List Archives

FW: Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements

for

From: Murphy, Sean
Date: Jan 28, 2020 10:37PM

-----Original Message-----
From: <EMAIL REMOVED> < <EMAIL REMOVED> >
Sent: Sunday, 26 January 2020 5:35 PM
To: Murphy, Sean < <EMAIL REMOVED> >
Subject: FW: [WebAIM] Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Alastair Campbell
Sent: Wednesday, 5 December 2018 8:38 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Contrast and Color Accessibility, Understanding WCAG 2 Contrast and Color Requirements

Jared Smith wrote:
> But if you are instead stating that the two states (on and off) have
> to be differentiable *from each other* with a 3:1 contrast ratio
> (assuming no other visual or text changes), then this conflicts with
> your previous statements. How are the on/off states covered, but the
> hover state not covered?

I think the confusion is assuming that a 'colour change' is the only differentiator, the requirement here is that *if* you rely only on a contrast change. This SC focuses on using contrast, but that isn't the only method.

Take this Android toggle button example:
https://androidician.files.wordpress.com/2014/09/output_potdse.gif
(animation warning)

Let's assume for the sake of discussion that the blue 'on' indicator contrasted with the grey background, and that the dark grey fill of the 'off' state also had contrast with the background. Neither do, but it's the example I could find in a few seconds of googling.

You go from a right-hand contrasting area to a left-hand one - it changes shape.

The grey doesn't have to contrast with the blue.
(Of course, there might be an issue with knowing that right is on and left is off, but that's a different issue.)

If you go in thinking "this component needs to have contrast so you can see it", that generally works for radio buttons, toggles, checkboxes etc. We did some analysis of examples, including from some of the common pattarn
libraries:
https://alastairc.ac/tests/wcag21-examples/non-text-contrast.html

So the things that determine 'this thing is a control' need to be discernable. For links that might be an underline (but then there's a separate requirment for focus indicator), for a checkbox the box and the tick are needed. For an input it might be a border, a single line, a different background, we can't just list these things because there is too much flexibility.

That's why the understanding doc says:
"any visual information provided that is necessary for a user to identify that a control exists and how to operate it must have sufficient contrast with the adjacent background."


> See how this quickly gets confusing? Authors (and accessibility folks
> like me) really need clear guidance on this - the supporting materials
> can't say that some states are covered and others not without clear
> descriptions of which are which - and explanations of how that aligns
> with the normative text.

Indeed, I'm afraid we have a slight backlog of issues in this area:
https://github.com/w3c/wcag/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+1.4
.11

I think once we've worked through those it should be clearer, we're also trying to get techniques done which should help, but can't do everything at once. If anyone can join up and pitch in, it would be most appreciated [1].

Cheers,

-Alastair

1] https://www.w3.org/WAI/GL/participation.php