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

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

Received on Saturday, 5 November 2016 14:44:52 UTC