W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2017

Re: Color Test: A formal proposal

From: Gregg C Vanderheiden <greggvan@umd.edu>
Date: Mon, 3 Apr 2017 12:40:39 -0400
Message-Id: <FA4E8331-6DC5-40C5-8F9F-FD80A1CEF0A7@umd.edu>
Cc: Dick <wayneedick@gmail.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
To: David MacDonald <david@can-adapt.com>
It is subtle but  you concern misses the point.

The USER will pick the two colors in real use — so they will pick colors that work for them.   So the colors chose are not relevant. 

The “loss of functionality” is everything BUT contrast.   if the user selects low contrast - it is their option.  For the test you just want to make sure that nothing else breaks when you change colors and that both colors can be specified.

make sense now?

g

 


Gregg C Vanderheiden
greggvan@umd.edu



> On Apr 3, 2017, at 6:03 AM, David MacDonald <david@can-adapt.com> wrote:
> 
> I think we also have to address the colour contrast issue. If the user changes colours to less that 4.5:1 so it either disappears or is hard to see, we can't call that a loss of information of functionality.
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Mobile:  613.806.9005
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
>             Including those with disabilities
> 
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
> On Mon, Apr 3, 2017 at 5:59 AM, David MacDonald <david@can-adapt.com <mailto:david@can-adapt.com>> wrote:
> >make sense?
> 
> Totally, that was my intent.  The SC language is pretty good right now  think, in its latest iteration. The question is the random test issue. 
> 
> Giving an auditor a random test which choses colours that the author didn't test seems like a recipe for confusion. And we want to make sure that we don't give the impression that an auditor can give the page a fail based on a random test that the author didn't check for. 
> 
> 
> 
> Cheers,
> David MacDonald
>  
> CanAdapt Solutions Inc.
> Mobile:  613.806.9005 <tel:(613)%20806-9005>
> LinkedIn 
>  <http://www.linkedin.com/in/davidmacdonald100>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
> GitHub <https://github.com/DavidMacDonald>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>   
>   Adapting the web to all users
>             Including those with disabilities
> 
> If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html>
> 
> On Sun, Apr 2, 2017 at 10:50 PM, Gregg C Vanderheiden <greggvan@umd.edu <mailto:greggvan@umd.edu>> wrote:
> I think It does work David.  
> 
> RATIONALE:
> The SC only says that it must be possible to change the colors and you only need 1 success to prove that that is true. 
> The SC does not require that ANY two choices would work.  Just that it is POSSIBLE to change them without loosing function .  It is up to the user to choose two colors that work for them. 
> 
> make sense?
> 
> 
> Gregg
> 
> 
> Gregg C Vanderheiden
> greggvan@umd.edu <mailto:greggvan@umd.edu>
> 
> 
> 
>> On Apr 1, 2017, at 7:07 PM, David MacDonald <david@can-adapt.com <mailto:david@can-adapt.com>> wrote:
>> 
>> This test is saying the dev only has to test one colour but is responsible for all 256,000,000. The auditor can fail him on things he didn't test.
>> 
>> It can't work like that.
>> 
>> Then the developer could get sued or fired for not meeting the WCAG even though they did everything they needed.
>> 
>> The way it should work is that the dev would to say in his statement of conformance, the values tested... just like "we tested with JAWS 18, on WIN and IE 11" and the auditor tests that. Now if the auditor decides to check something else and say, "hey I noticed this didn't work" that is a best practice statement. I do that all the time with devs
>> 
>> Having said that, if one colour can be overridden successfully many others will... 
>> 
>> On Apr 1, 2017 3:58 PM, "Gregg C Vanderheiden" <greggvan@umd.edu <mailto:greggvan@umd.edu>> wrote:
>> Just FYI
>> 
>> Technically — we don’t have any such things as “formal tests”  except for TECHNIQUES.
>> 
>> 
>> This can’t be a formal test unless the SC says that you must do exactly this - or rather  the SC must say  “  Content passes the following test"
>> 
>> you put it forward as an informal test — but the SC is the only criterion for passing the SC.  (that is what its name means—  success criterion.
>> 
>> The WG COULD propose the test as a ‘sufficient’ test of the SC.   That is — if you pass, you pass.
>> But you cannot say that if you fail you fail unless the SC says this specifically.
>> 
>> Gregg
>> 
>> Gregg C Vanderheiden
>> greggvan@umd.edu <mailto:greggvan@umd.edu>
>> 
>> 
>> 
>> > On Apr 1, 2017, at 2:49 PM, Wayne Dick <wayneedick@gmail.com <mailto:wayneedick@gmail.com>> wrote:
>> >
>> > I proposed this color test.
>> > It should work.
>> > The colors are selected randomly so that they support a 4.5:1 ratio.
>> > This test should be sufficient.
>> > It tests two random color choices (one dark one light).
>> > The combination is most likely a mud color (light or dark).
>> > The test looks at dark on light and light on dark.
>> > It is significant that !important is left off the first test.
>> > It should be run  twice, without and with !important.
>> > The non-important will flush out element level style.
>> > The important will flush real erroneous cases.
>> >
>> > Look for colors that do not change.
>> > Loss of functionality, images disappear, icons dispensary
>> >
>> > If colors do not change add-in background-image: none.
>> >
>> > Pay attention to borders and padding. These may also need to be specified.
>> >
>> > I would like to put this forward as a formal test.
>> >
>> > Wayne
>> >
>> >
>> 
>> 
> 
> 
> 
Received on Monday, 3 April 2017 16:41:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 08:04:09 UTC