Re: Re[4]: Colour Luminosity/Contrast for form inputs/controls/components

And talking about contrast for things other than text there are a couple things to keep in mind.

1) the amount of contrast needed to see controls and other objects is much less than the contrast needed to make out fine details on 10 strokes of letters. So the contrast requirements should not be anywhere near as high for other things as it does for the strokes of letters.

2) with letters you have the letter and the background. When you talk about other controls you may have things that have many different colors. Setting contrast requirements can make it very difficult or impossible to use a reasonable color spectrum for the objects if they are multicolored. One strategy for getting around this would be to put an outline around every object.

3) you will run into The same problems with varied backgrounds that you do with text. The objects however are typically bigger than letter stokes so again the contrast issues are not quite as severe.

Remember that the contrast requirements for words were not set to make it possible to see that there was a Word there but to be able to make out the individual small features in the letters so that you could tell one letter from another .    

One area that I see you focusing on that I think is good to focus on is the focus indicator. It currently has a rather ineffectual definition of having to be "visible". This is rather meaningless because if it were invisible it wouldn't be a focus indicator. It needs to be highly visible.   This is one item where the only thing we could get consensus on was that it be visible. We could then build techniques off of that as to how visible it should be and how to make it visible or more visible. We were not able to get any consensus for a stricter definition of visibility for the focus indicator.

Gregg

Sent from iPhone using dictation so expect transcription errors and ask if something doesn't make sense.  Thx

> On Nov 5, 2016, at 8:36 AM, "josh@interaccess.ie" <josh@interaccess.ie> wrote:
> 
> ------ Original Message ------
> From: "Jonathan Avila" <jon.avila@ssbbartgroup.com>
> [...]
>>  
>> I’ll tell you how Apple handles this with VO – so the same technique could be applied to the web – I think it’s possible with CSS also based on a quick Google search (http://stackoverflow.com/questions/3906983/css-two-color-borders)  Basically VoiceOver draws a double border for the focus indicator.  One box is white and one box is black – thus you always have black next to white no matter what other colors are around – simple.
> 
> Nice.
> 
> Josh
> 
> 
> 
>>  
>> Jonathan
>>  
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group 
>> jon.avila@ssbbartgroup.com
>> 703.637.8957 (Office)
>>  
>> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>> Check out our Digital Accessibility Webinars!
>>  
>> From: David MacDonald [mailto:david100@sympatico.ca] 
>> Sent: Wednesday, November 02, 2016 12:34 PM
>> To: Glenda Sims
>> Cc: josh@interaccess.ie; WCAG
>> Subject: Re: Re[2]: Colour Luminosity/Contrast for form inputs/controls/components
>>  
>> One thing bear in mind when considering sufficient contrast on focus indicators. It is likely that there're will be buttons of different colors and interactive elements of different colors. To maintain sufficient contrast with each tab press, the focus indicator would have to change colors depending on the color of the button for direct development that's landing on. That's a bit of a programming nightmare.
>>  
>> I don't know a way around that right now. Perhaps we could say something like sufficient contrast with the default Interactive element color. However on most sites that color is decided in the CSS. 
>>  
>> I think visible folks indicators important place to put some attention in the 2.1 ... And I'm interested n some creative solutions hurdles I'm talking about here...
>> 
>> Cheers,
>> David MacDonald
>>  
>> CanAdapt Solutions Inc.
>> Tel:  613.235.4902
>> LinkedIn 
>> twitter.com/davidmacd
>> GitHub
>> 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
>>  
>> On Wed, Nov 2, 2016 at 10:14 AM, Glenda Sims <glenda.sims@deque.com> wrote:
>> Great questions!  Laura Carlson, Jim Allan and I have been looking at proposed wording for a new success criterion called "Interactive Element Contrast (Minimum)".
>>  
>> So far the draft covers color contrast for:
>> important (non-text) information in an image
>> disabled interactive elements
>> borders of input elements
>> focus indicators
>> select indicators
>> Sounds like we need to add visual presentation of the interactive element itself.
>>  
>> I'll put some thought into this and draft some proposed language. 
>>  
>> Please note, we are in early draft stage.  The LVTF has not discussed this proposal in detail yet.  I have suggested it as an item for the agenda.  Hopefully we will be able to dive into this discussion this week on our LVTF call.
>>  
>> And...as Alastair said, the draft we've crafted is here: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Contrast_(Minimum)
>>  
>> To A11Y & Beyond!
>> Glenda
>>  
>> 
>> glenda sims    |   team a11y lead   |    deque.com    |    512.963.3773      
>> 
>> web for everyone. web on everything. -  w3 goals
>>  
>> On Wed, Nov 2, 2016 at 7:10 AM, josh@interaccess.ie <josh@interaccess.ie> wrote:
>> 1.4.3 is only for text currently, 
>> LVTF wants to expand to all info including ui and graphs etc...
>>  
>> +1
>> 
>> 
>>  
>> 
>> Cheers,
>> David MacDonald
>>  
>> CanAdapt Solutions Inc.
>> Tel:  613.235.4902
>> LinkedIn 
>> twitter.com/davidmacd
>> GitHub
>> 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
>>  
>> On Wed, Nov 2, 2016 at 5:37 AM, josh@interaccess.ie <josh@interaccess.ie> wrote:
>> I'm looking at contrast requirements for a client regarding form controls, radio buttons etc for a client, and WCAG does not seem to specify them. It seems 'implied' that 1.4.3 is relevant and there are techniques that touch on the subject (G183, G182, G111) but nothing definitive like. 
>>  
>> "If you have an UI component/input control, or radio button that a VIP user needs to see to select/interact with the luminosity requirements are x."
>>  
>> Am I missing something? Or is this something we need to address?
>>  
>> Thanks
>>  
>> Josh
>>  
>>  
>>