Re: Transient states

Hi,

The rationale for excepting the hover/focus state from SC 1.4.3 and SC
1.4.6 relies on the distinction between visible & unfocused versus
visible & focused. However, there is another distinction that is not
mentioned here: some implementations of skiplinks are either invisible
or focused & visible (i.e. skiplinks that only become visible on focus).
I would argue that the contrast requirements apply to this type of
skiplinks, otherwise the skiplinks would be unreadable for keyboard
users with certain vision impairments. How would we explain that SC
1.4.3 and 1.4.6 do not apply to the hover & focus states of "normal"
links but that they do apply to the type of "peekaboo skiplinks" that I
mentioned? As an exception to the exception?

Best regards,

Christophe


On 9/03/2016 16:58, James Nurthen wrote:
> So we are operating with complete information - this was Gregg's
> comment in the original issue
>
> GV:
> I would say that it would not be a failure for either a mouse or a
> keyboard focus.  Here is the rationale.
>
> the purpose of high contrast is to allow it to be read.  This is true
> for both the mouse and keyboard  because the person can simply read it
> before focusing on it.   They then focus on it and then activate it. 
> It  WOULD be nice if they could confirm it when selected -- but even
> with lower contrast they can probably still read it once they already
> know what it says.  But either way, they can move off of it and read
> it  - then move on to it and select it.  
>
> The alternative would be to require that it have enough contrast
> either way-- but then there might not be much difference between
> selected and not selected -- which would be more confusing and
> unusable for the person with low vision.
>
> So I would say it was OK and in fact might be a better design than if
> it "selected" and "non-selected"  both met the contrast rules.     
> And I don't think it would technically fail the SC either.
>
> Regards,
> James
>
> On 3/9/2016 7:51 AM, Jonathan Avila wrote:
>>
>> Ø  I’m not sure what you’d be raising a bug on though? The previous
>> WG response?
>>
>>  
>>
>> Not specifically a bug – but an issue with the interpretation.  That
>> is – I’d like another issue that overturns that decision.  That way
>> when this comes up – we can point to something that was discussed by
>> the working group.
>>
>>  
>>
>> Ø  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).
>>
>>  
>>
>> Yes, some text in the non-normative understanding documents would be
>> preferred.
>>
>>  
>>
>> Jonathan
>>
>>  
>>
>> Jonathan Avila
>>
>> Chief Accessibility Officer
>> SSB BART Group
>> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>
>>
>> 703.637.8957 (Office)
>> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter
>> <https://twitter.com/SSBBARTGroup> | Facebook
>> <https://www.facebook.com/ssbbartgroup> | Linkedin
>> <https://www.linkedin.com/company/355266?trk=tyah> | Blog
>> <http://www.ssbbartgroup.com/blog/>
>>
>> Check out our Digital Accessibility Webinars!
>> <http://www.ssbbartgroup.com/webinars/>
>>
>>  
>>
>> *From:*Alastair Campbell [mailto:acampbell@nomensa.com]
>> *Sent:* Wednesday, March 09, 2016 3:54 AM
>> *To:* Jonathan Avila; GLWAI Guidelines WG org
>> *Subject:* Re: Transient states
>>
>>  
>>
>> 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>, 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]
>> *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 
>>
>>  
>>
>> 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 
>>
>>  
>>
>> 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
>>
>> "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
>>
>>  
>>
>>  
>>
>
> -- 
> Regards, James
>
> Oracle <http://www.oracle.com>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415
> 987 1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065
>  
>


-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“It is possible to make a living making free software for freedom 
instead of closed-source proprietary malware for cops.” 
Jacob Appelbaum, 
<http://dissenter.firedoglake.com/2012/12/28/jacob-appelbaum-on-resisting-the-surveillance-state/>