Re: LVTF position on contrast requirements for interactive control states

I agree. The focus contrast is essential. I don't like hovers that fade
out, it is a pain, but I can live with it.  +1
Wayne

On Wed, Mar 16, 2016 at 2:05 PM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> In my opinion this is much better than the prior discussion/decision on
> the topic and I’d generally agree.  While I’d like to also consider hover
> state I’m happy to take the focus state alone for the current WCAG 2 and
> would accept this with an editorial change.  The term recommendation could
> be taken the wrong way to appear as advisory..  In reality it seems pretty
> clearly a failure to me and not just a recommendation.
>
>
>
> Jonathan.
>
>
>
> *From:* Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
> *Sent:* Wednesday, March 16, 2016 4:47 PM
> *To:* public-low-vision-a11y-tf@w3.org
> *Subject:* LVTF position on contrast requirements for interactive control
> states
>
>
>
> LVTF – read and let us know if you agree.
>
>
>
> Related to WCAG Issue 157: https://github.com/w3c/wcag/issues/157
>
>
>
> This question was posed: There is an implication that contrast
> requirements cover all states of links, buttons and inputs (hover, focus
> etc) but this is currently unclear and it would be good to have an explicit
> note to state this.
>
>
>
> The working group responded to a similar question in the past and
> indicated that the interactive states for controls such as the ones
> represented in CSS pseudo-classes for HTML:
>
> :focus (when the keyboard focuses the control)
>
> :hover (when the pointer device hovers over a control)
>
> : active (when the control is in the process of being interacted with, for
> example when a button is actively being clicked or pressed)
>
>
>
> The Working Group’s past response was that meeting the contrast criteria
> was not required to meet WCAG 2.0, and the basis for that decision was that
> users could move away from the control to read the un-focused or un-hovered
> state.  The point was made recently that for the appearance of a control
> when it receives keyboard focus, it is important to meet the contrast
> criteria because end users may not be able to use tab or shift-tab to move
> off of the control and ensure that they can view the control.
>
>    - A page has lots of space between controls (you can only view one
>    button or other control at a time, even with typical screen resolution,
>    because the buttons are spaced so far apart.
>    - A page has controls that are spaced more closely, but the end-user
>    increases the text size or uses a magnifier and the result is that the user
>    may not be able to see a control when he moves the focus to an adjacent
>    control.
>    - A page has a hidden skip navigation button which appears only when
>    focused.  Tabbing away from this button makes the button disappear.
>
> Given that these situations (particularly the second one) can occur on any
> page, the contrast of the focused state for all pages must meet the WCAG
> 2.0 contrast requirement.
>
>
>
> For :hover, it is possible for a pointer-device user to move the pointer
> slightly away from the control with the changed appearance of text during
> hover, so it is desirable but not required that such as control meets the
> color contrast requirement.
>
>
>
> For :active, the state change exists only while the control is being
> activated, so it is less critical that the contrast of text during this
> brief period meet contrast requirements.
>
>
>
> Recommendation:
>
> It is recommended that text of links and controls that changes at any time
> meets the appropriate contrast requirement in WCAG 2.0 Success Criteria
> 1.4.3. Given that it can be difficult to find enough color combinations to
> address the design needs and meet the contrast requirement, it is
> sufficient to meet the SC 1.4.3 contrast requirement for text that changes
> upon keyboard focus and allowable that text that changes when the link or
> control is in the active or hover states to not meet the SC 1.4.3 contrast
> requirement.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
> http://blogs.adobe.com/accessibility
>