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

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
>
>