Re: LVTF position on contrast requirements for interactive control states

Hi Andrew,

I agree. This is a big improvement over the current situation. Thank you.

Best Regards,
Laura

On 3/16/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 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
>


-- 
Laura L. Carlson

Received on Saturday, 19 March 2016 14:40:39 UTC