Re: Transient states

My comment had to do with times where the contrast FAILED during hover.  But PASSED at other times.    So this would not be a problem.

I think you are talking about when the contrast FAILS normally and PASSES only on hover (yes?).
     I think this is very bad practice - but WCAG only requires that something have a mechanism or way of  passing - not that it pass in its default presentation. 
  So unfortunately this would pass as well - not because of the SC wording — but because of the conformance wording.     
 (AND we cant require that everything pass in default or else closed captioning would be outlawed (all captions would have to be open)  and dozens of other problems.  In fact, where two disabilities need two different presentations we would have to drop one because it can’t be correct at default - in two different settings.   

So I think it is bad practice but not a violation — and we can’t make it a violation without deciding that the default should be for a particular group — and not another — and not what would be standard. 


Do you see what I mean?   or do you see something I am missing    (or did you mean something else all together? ) 


gregg

> On Mar 10, 2016, at 8:47 AM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 
> Gregg,
> 
> If this was just talking about hover I’d feel more in agreement as the hover state is trigged by the mouse movement and a low-vision mouse user can move the pointer to the side a few pixels.  Less convenient than reading the text directly, but not unworkable.
> 
> For a low-vision keyboard-only user, if they are zoomed in a lot or if the focusable items on the page are far enough apart that they don’t appear on screen at the same time, moving the focus off of the button in question so that it can be read also moves the item that you are trying to read out of the viewing area so it may have appropriate contrast now, but it is off-screen for the user.  
> 
> The same effect comes up for a skip-link that is hidden until focused.
> 
> Does this clarify the issue that we are talking about more, or do you not agree with this still?
> 
> Thanks,
> AWK
> 
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe 
> 
> akirkpat@adobe.com
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
> 
> From: CAE-Vanderhe <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
> Date: Wednesday, March 9, 2016 at 23:02
> To: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: Re: Transient states
> Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Resent-Date: Wednesday, March 9, 2016 at 23:03
> 
> 
> 
> This came up in our discussions during WCAG 2.0   
> 
> If the contrast is there naturally,  and hover or keyboard focus causes it to change, the contrast would NOT have to be maintained during the hover.   The person can read it before or remove the hover if they want to see it more clearly.    Remember conformance says the needs to be a way - not that it is always present. 
> 
> Now the reverse is would not pass (bad contrast until you hover) because you can’t hover with touch screen devices - and keyboard focus isnt available either. 
> 
> gregg
> 
>> On Mar 9, 2016, at 2:54 AM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
>> 
>> Hi Jonathan,
>> 
>> I agree, the normative text doesn’t appear to make an exception for interactive or transitory states. (I was one of the people surprised by the previous response.)
>> 
>> I’m not sure what you’d be raising a bug on though? The previous WG response?
>> 
>> Perhaps undoing that means adding some text to the understanding page for 1.4.3/1.4.6 to make clear it applies to visible transitory states (e.g. focus & hover).
>> 
>> Cheers,
>> 
>> -Alastair
>> 
>> 
>> From: Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>
>> Date: Tuesday, 8 March 2016 at 18:00
>> To: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com>>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
>> Subject: RE: Transient states
>> 
>> Alastair, thank you for bringing this up.
>>  
>> While I can certainly understand the active state not being covered as it occurs between when the user performs the action and when the action occurs – focus states occur when the user tabs to an element and thus this is likely to be an issue for users who rely on the keyboard.  Since we are talking about the contrast of text here – and the text is not inactive – I don’t understand how SC 1.4.3 and 1.4.6 do not apply.
>>  
>> The focus and hover state do not appear to fall under the Incidental clause: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
>>  
>> Unless someone can point me to an documented normative exception for this I’ll be opening an new issue at minimum for the focus state.
>>  
>> Jonathan
>>  
>> From: Alastair Campbell [mailto:acampbell@nomensa.com <mailto:acampbell@nomensa.com>] 
>> Sent: Tuesday, March 08, 2016 9:05 AM
>> To: GLWAI Guidelines WG org
>> Subject: Transient states
>>  
>> Hi everyone,
>>  
>> There was an item last week on defining ‘transient states’ with regards to this:
>> https://github.com/w3c/wcag/issues/157 <https://github.com/w3c/wcag/issues/157> 
>>  
>> The whole point may be moot now as Makoto Ueki pointed out that the group responded on this here:
>> http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html <http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html> 
>>  
>> So historically focus/hover/activate states are not covered by colour contrast in SC 1.4.3. That surprised a few people.
>>  
>> In case this gets re-visited I tried to find a way of differentiating transient states (such as hover) from really transient states (such as active).
>>  
>> In W3C terms these are generally referenced as 'Dynamic pseudo-classes’ and within those, 'user action pseudo-classes', but they are not defined by their timing element, and there is no differentiation from the CSS/HTML spec (that I can find). Both CSS and WCAG should apply across platforms, so definitions are difficult.
>>  
>> The closest thing is 'formal activation state’ in the WhatWG doc here:
>> https://html.spec.whatwg.org/multipage/scripting.html#in-a-formal-activation-state <https://html.spec.whatwg.org/multipage/scripting.html#in-a-formal-activation-state>
>> "An element is said to be in a formal activation state between the time the user begins to indicate an intent to trigger the element's activation behaviour"
>>  
>> So there is a potential avenue, but as I noted above, the point may be moot if none of them are covered.
>>  
>> Cheers,
>>  
>> -Alastair
>