Re: Transient states

My response to Gregg is:  First, sufficient contrast is not the same as “high contrast” – people with low vision are seeking the sufficient contrast requirement to apply.  Saying that you can simply read it before focusing it seems like a phrase that was written by someone without a visual impairment and may not hold true in the real world people who live with vision loss.  All too often I hear people say they understand what it’s like to be visually impaired when they take off their glasses.  It’s not the same.

Jon, as there was no Low Vision TF in February 2014 when this was written I read Gregg’s “sufficient contrast” as shorthand for “sufficiently high contrast”.  This is different from what we may hear from the LVTF for a recommendation moving forward, but it is what I believe he was saying.

If you take the example of screen magnification software where you see a small view of the screen and as you tab the view is focused to a link the user might not be able to get the text with sufficient contrast into the magnified view at all.  Tabbing past or shift+tabbing might move the magnified view away from the text link.

This is a very good argument for why the onfocus state needs to meet the contrast requirement, and it is very similar to the point Christophe raised about hidden skip links.  I don’t recall this coming up in the discussion from two years ago.

What grounds under the normative document nor authority does he have to carve out such an exclusion to WCAG?   The normative text indicates that text and images of text must have a specific contrast ratio and changing that undermines the success criteria.

Gregg isn’t carving anything out.  This comment was in the WG notes section of the issue so on its own doesn’t mean anything.  The Working Group discussed the issue that was raised and offered the advice, in part based on Gregg’s comments, but with a survey and working group discussion on the weekly call.  This is still just non-normative advice, and based on the arguments made it sounds like we should re-think the response.

James suggested that the active state might not need the high-contrast treatment, and I can’t think of a reason to disagree with that, but thanks for raising the point about magnification and a shifting viewport as I think that helps clarify the need.

AWK

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: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Wednesday, March 09, 2016 10:59 AM
To: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Subject: Re: Transient states

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



--
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<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[Green              Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment