Re: Colour Luminosity/Contrast for form inputs/controls/components

> Seems a bit of a hack to require both border, and Outline
 ...and...
> Double line with two different colours would be awesome

As a Technique, this may very well address the problem statement, however
we must be careful not to be overly prescriptive of our expectations - we
cannot for example 'mandate' this as a Success Criteria going forward.

Cheers!

JF

On Mon, Nov 7, 2016 at 9:24 AM, Chakravarthula, Srinivasu <
srchakravarthula@informatica.com> wrote:

> Absolutely I agree too. Double line with two different colours would be
> awesome.
>
> Regards,
> Srinivasu Chakravarthula | Informatica | @CSrinivasu
> Sent from my iPhone
>
> On 07-Nov-2016, at 19:32, David MacDonald <david100@sympatico.ca> wrote:
>
> Yes I agree we need add a good focus indicator requirement into 1.4.3, and
> as a core technique, I really like John's idea of the double line with two
> different colours (light and dark) so that it will have sufficient contrast
> over any background.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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 Sat, Nov 5, 2016 at 10:44 AM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 05/11/2016 14:28, Gregg Vanderheiden wrote:
>>
>>> 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.
>>>
>>
>> Unless the controls/objects rely on the user being able to recognise fine
>> details too. Think for instance icons using only thin outline strokes
>> (rather than solid shapes/colours).
>>
>> The same way that some blocky fonts which DON'T have any fine details
>> would also not require as high a contrast ratio perhaps as
>> thin/elaborate/detailed fonts.
>>
>> It's a slippery slope to try and differentiate here, I'd say (as it
>> probably exposes shortcomings even in the current text - we've already seen
>> how the current definition of "large scale text" is arguably flawed, and
>> we've not even tackled what "bold" actually is, keeping in mind different
>> fonts can have wildly different visual appearances, x-heights, optical
>> weights, issues relating to kerning, details, etc).
>>
>> [...]
>>
>> 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 .
>>>
>>
>> Is this documented anywhere? On first reading, it seems strange that the
>> concern is to be able to see details, but that it's not really essential
>> that the text itself be legible (recognised as a word)?
>>
>> 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.
>>>
>>
>> Agreed. "visible" sets the bar too low. Section 508 1194.21 (c) goes a
>> tiny step further in requiring a "well-defined on-screen indication of the
>> current focus", but even there "well-defined" is, ironically, not well
>> defined as a term. It would be good to get some qualitative and
>> quantitative definition into the spec around this aspect.
>>
>> P
>>
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion