WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jared Smith
Date: Dec 5, 2018 9:03PM

Alastair Campbell wrote:

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

Thank you for compiling these. This is very helpful.

> 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.

This aligns with my thoughts. I think it's useful to recommend visual
changes on hover for many interactive components to reinforce that
they are interactive, but a 3:1 contrast ratio requirement for those
changes would be constraining to many designs and could result in a
less accessible experience.

> 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.

I'm not sure Gmail should be considered a model for optimal user experience. :-)

Adam Silver provides a comprehensive analysis of this topic at
https://medium.com/simple-human/buttons-shouldnt-have-a-hand-cursor-b11e99ca374b
As a quick summary, Microsoft
(https://docs.microsoft.com/en-us/windows/desktop/uxguide/inter-mouse#hand-pointers),
Apple (https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/mouse-and-trackpad/),
and the CSS specification
(https://www.w3.org/TR/CSS21/ui.html#propdef-cursor) all specify that
the hand/pointer cursor is only for links - elements that will take
the user somewhere else. Buttons, text boxes, checkboxes, sliders,
select menus, etc., etc., do not have this functionality and thus
should not provide this visual affordance.

While changing the cursor to the pointer for buttons is easy to do,
it's a violation of at least the spirit of CSS, even though it is
commonly done (e.g., Gmail).

> > 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.'

Indeed. This has been helpful for me to explore this topic more fully.
These things are not easy to define or explain - and I applaud all of
you that do the hard work to put this into guidelines and supporting
materials. I'd be happy to review and provide feedback on an updated
Understanding document for this success criterion.

Thanks again for your effort on this.

Jared