Re: Transient states

It really seem like there is no difference between focused and hover text
compared to normal link text. You frequently have need to read both. If you
are tabbing, the landing link might not even be on the same viewport. This
happens more frequently with large print. The letter of the criteria refers
to text and it is clear about what  exceptions are allowed. Focus and hover
are not among the normative exceptions. I think WCAG WG engaged in a little
interpretive overreach on this one. It is such a divergence from normative
language. It just surprised me a lot. I just never imagined that focus and
hover text cold be interpreted as anything but text people need to read.

That was a good little piece of archival research, Allister. Jon, I think
you should post an issue so we can rescind the interpretation.

Wayne





On Wed, Mar 9, 2016 at 10:02 AM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  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.
>
>
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> Jonathan
>
>
>
> Jonathan Avila
>
> Chief Accessibility Officer
> SSB BART Group
> 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
> *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
>
> 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
> <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>
> *Date: *Tuesday, 8 March 2016 at 18:00
> *To: *Alastair Campbell <acampbell@nomensa.com>, GLWAI Guidelines WG org <
> 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
> <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
>
> [image: Oracle] <http://www.oracle.com>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood Cty, CA 94065
> [image: Green Oracle] <http://www.oracle.com/commitment>Oracle is
> committed to developing practices and products that help protect the
> environment
>