RE: Does 1.4.1 cover differences in state?

Yes, that is the meaning of it here. I did not modify that term. it was 
pre-existing. I agree that the Understanding doc will need to make it 
clear what that means so people do not think it means 'currently focused', 
etc.
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:   "White, Jason J" <jjwhite@ets.org>
To:     Michael Gower <michael.gower@ca.ibm.com>, James Nurthen 
<james.nurthen@oracle.com>
Cc:     "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>, Alastair Campbell 
<acampbell@nomensa.com>
Date:   2017-11-17 12:06 PM
Subject:        RE: Does 1.4.1 cover differences in state?



By “active” do you mean “not disabled” (as in aria-disabled=false)? If so, 
clarification would be helpful, as there doesn’t seem to be a generally 
accepted term for this concept.
 
From: Michael Gower [mailto:michael.gower@ca.ibm.com] 
Sent: Friday, November 17, 2017 10:29 AM
To: James Nurthen <james.nurthen@oracle.com>
Cc: w3c-wai-gl@w3.org; Alastair Campbell <acampbell@nomensa.com>
Subject: Re: Does 1.4.1 cover differences in state?
 
I'm trying to tackle these different scenarios in the Understanding text 
of Graphics Contrast, where pertinent. We may also need to add additional 
material to the Understanding doc for 1.4.1.
I will note that the combination of sufficient Graphics Contrast in 
combination with Use of Color makes for some complicated scenarios but SO 
FAR logically consistent guidance.

However, we may need to rejig the wording slightly for 1.4.11 to address 
some edge cases. It currently states:
User Interface Components
Visual information used to indicate states and boundaries of active user 
interface components, except where the appearance of the component is 
determined by the user agent and not modified by the author.

I think this should more properly read something like:
User Interface Component boundaries
Visual information used to indicate boundaries of active user interface 
components, except where the appearance of the component is determined by 
the user agent and not modified by the author.
User Interface Component states
Visual information used to indicate states of active user interface 
components, except where the enhancements determined by the user agent are 
not suppressed by the author.

Folks may want to review C15: Using CSS to change the presentation of a 
user interface component when it receives focus

James has already pointed out the onhover effect for the four buttons that 
appear at the top of this (and every) WCAG page. This page also provides 
two examples which appear to be contraventions of Use of Color, until one 
realizes that the examples, as noted by Steve, are enhancing the visual 
appearance "when an interactive element has focus or when a user hovers 
over it using a pointing device "

So, for the rollover effect, the mouse cursor shape change indicates the 
interact item beneath. So while the author effect is only Use of Color, it 
is not the sole indicator. In the linked working example, for the input 
field, the flashing insertion point also indicates focus. For the radio 
buttons, the focus rectangle provides the redunancy beyond the yellow 
highlight enhancement. I will say that the examples they provide are to me 
questionable design decisions, but they are 'allowable' as long as the 
author has not suppressed the native browser effects.

I've broken out boundary from state effects for this precise reason. I 
believe the language's intent is consistent with the philosophy of G183: 
Using a contrast ratio of 3:1 with surrounding text and providing 
additional visual cues on focus for links or controls where color alone is 
used to identify them 

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:        James Nurthen <james.nurthen@oracle.com>
To:        w3c-wai-gl@w3.org
Date:        2017-11-16 11:28 AM
Subject:        Re: Does 1.4.1 cover differences in state?




On 11/16/2017 11:11 AM, Repsher, Stephen J wrote:
Okay, so you’re more or less singling out hover, but I think it then comes 
down to how hover is used.
 
A typical use case of hover is to indicate a clickable area is now under 
the pointer, however that information is redundant since the mouse cursor 
will also change so long as a proper role is in place per 4.1.2 and 
there’s no funny CSS business with the cursor.  I’d agree no 3:1 is 
required there since it is not the only means.  If the cursor did not 
change though, I think it should fail.  Agreed?
Sure. Sounds reasonable - although there are probably exceptions to this. 
I'm not sure I want to go down the route of thinking of all of them right 
now as I have a lot of catching up to do post TPAC - and this seems lower 
priority than other things.
 
But then take a more complex example like a drag and drop operation.  The 
pointer may stay with the “grabbed” cursor when dragging something over an 
area where the object can be dropped, and color alone on hover may be used 
to indicate you’ve reached a droppable area.  That should fail if not 3:1 
or some other means, agreed?
Probably but I would again have to think a little more about it. If there 
are other accessible manners to do the same thing (which are "equivalent") 
this may be a case where I would allow it and fall back on a conforming 
alternate version.
 
Steve
 
From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Thursday, November 16, 2017 1:50 PM
To: Repsher, Stephen J <stephen.j.repsher@boeing.com>; w3c-wai-gl@w3.org
Subject: Re: Does 1.4.1 cover differences in state?
 
Yes. Some state differences are required. 1.4.1 states:
Color is not used as the only visual means of conveying information, 
indicating an action, prompting a response, or distinguishing a visual 
element.
So the "pressed" state of a toggle button is a way of conveying 
information so if "color" is the only way this is indicated then it needs 
to meet a 3:1 ratio between the pressed and unpressed colours.
The same for a "selected" tab page
A link with no underline falls into the either "indicates an action" or 
"distinguishing a visual element" 
However I don't believe a hover state falls into any of these so don't 
believe it needs to meet this.

Regards,
james

On 11/16/2017 10:38 AM, Repsher, Stephen J wrote:
Hi James,
 
The proposed Graphics Contrast SC does not attempt to cover differences in 
state, but I think this is an important question and I’m confused by your 
conflicting responses (or at least that’s how I perceive it).
 
Going back to your words at 
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0436.html...

 
Mike: 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.
 
James: 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)
 
James: 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.
 
 
So where is the misunderstanding occurring here?  Do you feel 1.4.1 
applies to some state differences but not others?
 
I think this will be an important point to ultimately clarify in the 
respective Understanding docs for these SC.
 
Steve
 
From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Thursday, November 16, 2017 11:32 AM
To: w3c-wai-gl@w3.org
Subject: Re: CFC - Graphics Contrast
 
No it would not. 1.4.1 does not mention the word state and include a 
definition which includes hover. Hover does not fit into the things which 
fail 1.4.1
Take for example the page 
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html

There are contents, intro, Previous and Next buttons at the top of the 
page. The only difference when they are hovered is the background color.
The background color is #dde and the hover background color is #aae
The ratio between these is 1.6:1 
I would not fail this page and I object to any SC which would fail this. 
My current reading of this new SC along with the definition of state 
proposed would and hence I object.
 
On 11/16/2017 7:54 AM, Repsher, Stephen J wrote:
Adding to what Alastair is saying, I’m confused by the objection because, 
as you pointed out, using color alone to differentiate between hover and 
non-hover would be a violation of 1.4.1.  Only when the 2 states are 
adjacent and touching would this SC come into play, but the 3:1 ratio 
requirement is the same.
 
Steve
 
From: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Thursday, November 16, 2017 3:03 AM
To: James Nurthen <james.nurthen@oracle.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: RE: CFC - Graphics Contrast
 
> Requiring hover to have sufficient contrast ratio to non-hover states 
has no accessibility requirements behind it as far as I know and would 
unnecessarily limit color choices in an already limited palette.
 
Hi James,
 
I don’t think that was discussed directly, but in order for that to be an 
issue the controls in different states would have to be adjacent, i.e. 
touching. Even without a mention of states, I think that would be an issue 
in current WCAG conformance.
 
There was some discussion about whether ‘existing’ was a state, and people 
thought that wasn’t clear so ‘boundaries’ was added:
“Visual information used to indicate states and boundaries of active user 
interface components”
 
(Still with the intent that if it isn’t there, you don’t have to add 
something.)
 
Does that help?
 
-Alastair
 
-- 
Regards, James 
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video: 
james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Oracle is committed to developing practices and products that help protect 
the environment 
 
-- 
Regards, James 
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video: 
james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Oracle is committed to developing practices and products that help protect 
the environment 

-- 
Regards, James 
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 | Mobile: +1 415 987 1918 | Video: 
james.nurthen@oracle.com
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
Oracle is committed to developing practices and products that help protect 
the environment 
 


This e-mail and any files transmitted with it may contain privileged or 
confidential information. It is solely for use by the individual for whom 
it is intended, even if addressed incorrectly. If you received this e-mail 
in error, please notify the sender; do not disclose, copy, distribute, or 
take any action in reliance on the contents of this information; and 
delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.