Re: Graphics contrast comments overview

> At the least, can we work disabled controls into the AAA SC discussed?

+1  I would support that in the AAA SC, with an additional 'note' in the
Understanding that encourages that, even at the AA level (without
specifically mandating it. I.e. - a strong 'hint' would be beneficial)

JF

On Wed, Nov 15, 2017 at 9:43 AM, 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.
> 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
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
>  V8T 5C3
> <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g>
> 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
>
>
>
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion