WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Alastair Campbell
Date: Dec 5, 2018 5:57PM

Jared Smith wrote:
> But what if color/contrast was the ONLY indication of
> state, particularly hover state?

I'm compiling the issues to make one update, and found we have
discussed this aspect already:
https://github.com/w3c/wcag21/issues/913#issuecomment-393975067

In that compilation, I gathered together this set of updates to make
to the understand docs, just bullets to use at this stage.

NOTE: Very draft, still to be approved.
-------------------
From 1.4.11:
- Components must continue to have contrast in different states
("required to identify").
- Where a state indicates functionality of the component (e.g. a check
in a checkbox), that aspect must have sufficient contrast ("required
to identify … states"). However, it does not create a requirement to
differentiate states by color internally (e.g. between default and
hover, visited link, visited + hover etc.). A better term than
"functionality" would be useful there.

In combination with Focus Visible (2.4.7) & Use of Color (1.4.1):
- if the focus indicator relies on color alone (so all three SCs!),
that must provide contrast compared to the non-focused state. (E.g.
changing the background color of a button.)
- if the focus indicator adds/removes parts of the component, or
changes the shape of the component, that change must have contrast.
(e.g. adding thickness to a border that has contrast, or adding a
separate outline.) However, it doesn't have to contrast with itself if
it changes the shape.

Not in scope:
- Boundaries for links / buttons.
- Default (untouched) focus indicators.
- Measurement is against adjacent colors of the component, not
different states within the component (except when color-change-only
is used for focus state).
- Hover / visited state (except that the component must continue to
have contrast). Whilst desirable that a component would indicate hover
state in a perceivable way, it is not required by 1.4.11.
------------------

> I'd be happy to hear your opinions on the "Pass or Fail?" scenarios.
> It's still not clear to me what WCAG requires here.

As per the above, differentiating hover isn't required, but I was
hesitant to say that because you asked:

> ... Cursor change would not be applicable to buttons which do not
> (and, arguably, should not) do so on hover.

What's the argument about not having a pointer change on hover? I had
thought adding `cursor: pointer` (or whatever the CSS is) would be an
easy thing to do. All the 'buttons' in the Gmail interface I'm using
do that.

There might have been an assumption that hover would generally change,
and I'm not sure that was realised when that aspect was discussed, as
we were talking about links initially. Overall I think requiring a
hover state is problematic, and therefore requiring contrast for it is
also problematic. Let me come back about that.

> I do hope that corrections to the mistakes and ambiguity
> in the already-published WCAG materials would be given priority
> treatment - I think giving incorrect or ambiguous guidance is more
> detrimental than not giving guidance at all.

We did spend many hours on it, and go through hundreds of examples,
the problem is distilling that. It helps to have conversations like
these to iterate that distillation.

Do the above notes help? I'll try to get that into the understanding
docs soon, via the working group process.

-Alastair