Re: Transient states

I would support that.

On Wed, Mar 9, 2016 at 4:47 PM, Wayne Dick <wayneedick@gmail.com> wrote:

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