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> 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' <john.foliot@deque.com <mailto:john.foliot@deque.com>>; 'Katie Haritos-Shea' <ryladog@gmail.com <mailto:ryladog@gmail.com>>
> Cc: 'David MacDonald' <david100@sympatico.ca <mailto:david100@sympatico.ca>>; 'CAE-Vanderhe' <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>; 'Jason J White' <jjwhite@ets.org <mailto:jjwhite@ets.org>>; 'Sailesh Panchang' <sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com>>; 'Andrew Kirkpatrick' <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>; 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org <mailto: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 tink.uk <http://tink.uk/> Carpe diem