W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2016

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

From: Chakravarthula, Srinivasu <srchakravarthula@informatica.com>
Date: Mon, 7 Nov 2016 14:24:28 +0000
To: David MacDonald <david100@sympatico.ca>
CC: "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
Message-ID: <B0F21201-C6C1-4B1B-B2AC-FF46A1900D75@informatica.com>
Absolutely I agree too. Double line with two different colours would be awesome.

Srinivasu Chakravarthula | Informatica | @CSrinivasu
Sent from my iPhone

On 07-Nov-2016, at 19:32, David MacDonald <david100@sympatico.ca<mailto: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.

David MacDonald

CanAdapt Solutions Inc.

Tel:  613.235.4902





  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<mailto: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.


Patrick H. Lauke

www.splintered.co.uk<http://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 Monday, 7 November 2016 14:25:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:07 UTC