Re: Graphics contrast comments overview

As per the note to SC 1.4.1, one needs to take recourse to Guideline
1.3 which I interpret to mean 1.3.1 here when a presentation mechanism
other than color is relied to convey info-relationships.
So if contrast is used to distinguish the state of an element, is it
not covered by 1.3.1 requiring programmatic determination?
Thanks and regards,
Sailesh


On 11/15/17, James Nurthen <james.nurthen@oracle.com> wrote:
>
> On Nov 15, 2017, 8:46 AM -0800, Michael Gower <michael.gower@ca.ibm.com>,
> wrote:
>> There is no language requiring a contrast minimum between the states
>> themselves. I would really like that to at least be captured in the
>> Understanding doc, if it can't be part of the SC, because being unable to
>> differentiate between states is as much of a problem as not being able to
>> differentiate between controls.
> I always fail this on 1.4.1 Use of Color: Color is not used as the only
> visual means of conveying information, indicating an action, prompting a
> response, or distinguishing a visual element. (Level A)
>
> If the ratio is 3:1 or greater then it is no longer color alone (hue and
> lightness) so no longer fails 1.4.1. As such I don’t think this needs to be
> in this SC.
>
>> The same concern applies for disabled versus enabled controls.
>>
>> Speaking of disabled controls, we exclude disabled controls from contrast
>> considerations completely, but I've always felt that if a designer bothers
>> to put a disabled element in the UI, that element's visual presence is
>> important, and should be discernible with some minimum contrast (even if
>> it is reduced). Every designer balks when I say 'Okay, if it's not
>> important, why not remove it from your design entirely until it is
>> active?'
>>
>> At the least, can we work disabled controls into the AAA SC discussed?
>> Alastair, I'd be happy to help try to craft that.
>>
>> Michael Gower
>> IBM Accessibility
>> Research
>>
>> 1803 Douglas Street, Victoria, BC  V8T 5C3
>> gowerm@ca.ibm.com
>> voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034
>>
>>
>>
>> From:        Alastair Campbell <acampbell@nomensa.com>
>> To:        Jonathan Avila <jon.avila@levelaccess.com>, WCAG
>> <w3c-wai-gl@w3.org>
>> Date:        2017-11-15 08:28 AM
>> Subject:        Re: Graphics contrast comments overview
>>
>>
>>
>> Hi Jon,
>>
>> > if the author uses a border to communicate the role of something
>> > then the aspect has to meet the contrast requirements.
>>
>> Agree. Also, I noticed we missed out the default-appearance exception, so
>> I’ve updated that to say:
>> “Visual information used to indicate state for active user interface
>> components, except where the appearance of the component is determined by
>> the user agent and not modified by the author.”
>>
>> > It doesn't require an author provide that affordance if they didn't.  So
>> > if I choose to make a piece of text blue and have it function like a
>> > button nothing needs to be done other than the contrast of the blue text
>> > in the non-focused state or non-pressed state of that button.
>>
>> Agree.
>>
>> > If I use a solid background to make something look like a button then I
>> > have to make sure the edge of the background has sufficient contrast
>> > from the surrounding pixels outside of the focused or pressed state.
>>
>> Agree.
>>
>> > If I have multiple buttons with some in pressed and others in
>> > non-pressed states the difference between the colors used for the
>> > pressed states need to have a 3:1 ratio as well.
>>
>> Agree. It is also worth considering the ‘adjacent’ aspect, if buttons are
>> not immediately adjacent, then they do not have to contrast with each
>> other.
>>
>> > Focus indicators need to provide 3:1 contrast as well.  Is that right?
>>
>> Yes, although with-what depends on what they are adjacent to.
>>
>> Cheers,
>>
>> -Alastair
>>
>>
>>
>>
>


-- 
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

Received on Thursday, 23 November 2017 02:50:55 UTC