RE: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)

Gregg wrote:
> 

> can’t extend this to ICONS unless you very carefully define icon icon art
> and figure out how to handle the fact that you can only have one color
> other than black and white and still have everything contrast with everything
> else.  Mathematically impossible.   You can try it.

> 

> 

> But I go back to the comment above.   What is it we are trying to solve.  Text
> on pages that can be displayed in any desired contrast?    This is already in
> WCAG. 

 

Hi Gregg,

 

The current gap in WCAG, as I (and others) see it is that color contrast requirements are today *only* associated to text, which leaves an important class of “on screen object” outside of the requirement – actionable graphics (icons or similar).

Use-case: 

A web-page/web-app has a “print” icon located in the top right corner: clicking on that (through the magic of JavaScript) loads the same page into the same/or different window, but with the print style-sheet referenced, and also exposes the print functionality of the user’s system. (Putting aside whether or not they should be doing this; we see it in the wild all of the time). 

 

The problem statement however is that the small graphic of a printer [sic] is light gray on white, so that the actionable element (whether a font icon, or a .png, or…) is not ‘Perceivable’ to a low vision user. 

This call to action, whether it is text surrounded by the anchor tag, or a graphic similarly marked-up, is, by being an actionable item, critical to those LV users, but the wording of WCAG today excludes (omits?) that possibility, as it focuses exclusively on “text” or “Images of text”: 

 

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)


Thus I’d like to see the inclusion of “actionable graphics” or similar wording as also requiring sufficient contrast and/or being modifiable (when possible?) moving forward. Happy to have that word-smithed as required, as long as we capture the key essence of the requirement.

 

JF

 

 

From: Gregg Vanderheiden RTF [mailto:gregg@raisingthefloor.org] 
Sent: Monday, February 22, 2016 8:07 PM
To: John Foliot <john.foliot@deque.com>
Cc: tink@tink.uk; Katie Haritos-Shea <ryladog@gmail.com>; David MacDonald <david100@sympatico.ca>; Jason J White <jjwhite@ets.org>; Sailesh Panchang <sailesh.panchang@deque.com>; Andrew Kirkpatrick <akirkpat@adobe.com>; GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Re: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)

 

 


gregg 

 

On Feb 22, 2016, at 6:37 PM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com> > wrote:

 

…and yet, as we’ve seen already on this thread, increasing contrast negatively affects other user-groups (COGA), which effectively leaves us with a real dilemma: how do we address the needs of both groups? 

 

Thanks John.   This is exactly the question.

 

And the answer is — to prescribe any presentation or limit any presentation.   The WCAG is designed to allow users to customize their presentation.    For contrast - it sets a minimum — but it is quite low and far from the High or Low contrast —   at  4.5 to 1      (High contrast is   20:1  an   1:1 is of courses no contrast. 





Can it be done simultaneously? 

 

Not on the same screen at the same time — unless moderate contrast is good enough for both.       If one needs high and one needs low — then WCAG provides machine access to the content to allow it to be presented at any contrast and with any colors that a person finds best. 





Is color contrast issues an outlier here, or do we envision other emergent SC that may cause the same or similar discrepancies?

 

Color contrast is a bit of a problem.    Unless you know the color vision - you do not know if a color contrast is of any use or just makes real contrast worse (one way or the other).  That is why WCAG is based on luminosity which is preserved approximately across color visions differences or even no color perception. 





 

Off the top of my head, I could perhaps envision a new Success Criteria that says something along the lines of “Page Content [sic] MUST allow the end user to adjust contrast between the ranges of ___ (whatever is a reasonable low-end for COGA needs) and ___ (whatever is a reasonable high-end for LV, etc.)”  

 

This capability is already provided in WCAG through AT.    If we are saying that every Website should build in all the AT needed by all types, degrees and combinations of disability directly — then I think we have gone too far — and in fact cannot do this technically. 





- in other words mandating customization-ability of the page/site in question. One possible Technique would be to offer the end user the ability to select a “skin” or color scheme upon first visit (with perhaps setting a cookie to remember the user’s choice?...  I don’t know, I’m thinking out loud here…)

 

Good to do.  But 



 

What I would certainly bristle at however would be something along the lines of:




SC 1.4.3 (and/or) 

SC 1.4.3.1LV (and/or) 

SC 1.4.3.2COGA  (and/or)
SC 1.4.3.3MOBILE

 

…that to me is a recipe for confusion and non-adoption.

 

Agree

 

Also seems to discriminate against all the other disabilities.

 

And these are  OR  so I only have to do one  and forget the others? 

 

 









(Slightly off-tangent – for a thread already way off tangent – I *could* envision “extending” SC 1.4.3 to cover icons and other key actionable graphics on a page, which is currently not covered at all by WCAG 2.0: now *THAT* I could see as a SC 1.4.3.1 sub-set/sub-section)

 

can’t extend this to ICONS unless you very carefully define icon icon art and figure out how to handle the fact that you can only have one color other than black and white and still have everything contrast with everything else.  Mathematically impossible.   You can try it.

 

 

But I go back to the comment above.   What is it we are trying to solve.  Text on pages that can be displayed in any desired contrast?    This is already in WCAG. 

 

Pages that have built-in AT for each disability?     Don’t think this is possible or practical.  

 

But whatever - before we throw solutions at the wall - we should figure out what we are trying to do.    And if we already can do it or now.

 

thx all

 

Gregg

 





 

JF

 

From: Léonie Watson [ <mailto:tink@tink.uk> mailto:tink@tink.uk] 
Sent: Monday, February 22, 2016 4:17 PM
To: 'John Foliot' < <mailto:john.foliot@deque.com> john.foliot@deque.com>; 'Katie Haritos-Shea' < <mailto:ryladog@gmail.com> ryladog@gmail.com>
Cc: 'David MacDonald' < <mailto:david100@sympatico.ca> david100@sympatico.ca>; 'CAE-Vanderhe' < <mailto:gregg@raisingthefloor.org> gregg@raisingthefloor.org>; 'Jason J White' < <mailto:jjwhite@ets.org> jjwhite@ets.org>; 'Sailesh Panchang' < <mailto:sailesh.panchang@deque.com> sailesh.panchang@deque.com>; 'Andrew Kirkpatrick' < <mailto:akirkpat@adobe.com> akirkpat@adobe.com>; 'GLWAI Guidelines WG org' < <mailto:w3c-wai-gl@w3.org> w3c-wai-gl@w3.org>
Subject: RE: Coming to a decision on 2.2

 

From: John Foliot [ <mailto:john.foliot@deque.com> mailto:john.foliot@deque.com] 
Sent: 22 February 2016 19:20
"The fact that a TF that is looking specifically at issues related to Low Vision users (or Cognitive users, or Mobile users – which sort of is everybody) helps bring focus to those types of needs, and ensures that the next-gen WCAG addresses shortcomings that specifically affects that group, but I will suggest that increasing the contrast requirements [sic] will benefit not only LV users, but perhaps Mobile users and Seniors as well, so making it a “Low Vision” Success Criteria in name feels (to me) wrong."

 

+1

 

I think it will also cause confusion. The 2.0 SC is intended to provide sufficient contrast for people with low vision. If an extension SC provides a better recommendation, it will effectively render the original SC obsolete.

 

Updating guidance is progress and is a good thing (in many respects it's already long overdue), but trying to have conflicting SC exist in the same time/space seems like we're asking for trouble.

 

Léonie.

 

-- 

@LeonieWatson  <http://tink.uk/> tink.uk Carpe diem