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

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

From: John Foliot <john.foliot@deque.com>
Date: Mon, 7 Nov 2016 11:25:36 -0500
Message-ID: <CAKdCpxy9iZ_BPsdaSODZG+N8OvXV0Pq5wYDb7-0CabUCCu3XnA@mail.gmail.com>
To: "Chakravarthula, Srinivasu" <srchakravarthula@informatica.com>
Cc: David MacDonald <david100@sympatico.ca>, "Patrick H. Lauke" <redux@splintered.co.uk>, WCAG <w3c-wai-gl@w3.org>
> Seems a bit of a hack to require both border, and Outline
> 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.



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.

Advancing the mission of digital accessibility and inclusion
Received on Monday, 7 November 2016 16:26:12 UTC

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