RE: Transient states

Ø  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<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]
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