WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Detlev Fischer
Date: Dec 5, 2018 11:07PM

I think this is a very good summary of adequate requirements - especially differentiating between ‚functional states‘ (‚states to convey critical affordances‘) and the host of other states. I agree not to extend the focus indication requirement to hover states - the simple reason that the cursor / finger/ stylus is right there over the element should suffice, at a minimum level.
This thing is just that it *is* complex to delineate the requirement exactly, so I fear it will remain not easy to grasp / communicate what is required. Cheers, Detlev

Sent from phone

> Am 06.12.2018 um 01:57 schrieb Alastair Campbell < <EMAIL REMOVED> >:
>
> 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
> > > >