RE: LVTF position on contrast requirements for interactive control states

Currently the understanding documents for SC 1.4.3<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html> exclude inactive user interface elements by categorizing them as incidental.

Incidental: Text or images of text that are part of an inactive user interface component<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#user-interface-componentdef>, that are pure decoration<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#puredecdef>, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

As for placeholders – contrast tends to be an issue but you make a good point about differences in appearing conveying that it’s a placeholder.  I suppose it depends on whether the same information is communicated somewhere else.

Jonathan


From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Wednesday, March 23, 2016 12:18 PM
To: Katie Haritos-Shea; Scott McCormack
Cc: Andrew Kirkpatrick; public-low-vision-a11y-tf; Rochford, John
Subject: Re: LVTF position on contrast requirements for interactive control states

Hi everyone,

I agree with the all-states having sufficient contrast for things like hover/focus, but is this the right time/place to bring up the ones that often miss the contrast requirements?

The difficult examples that come up for us in audits are inputs/buttons which are ‘disabled’ (I.e. there but not functional), and placeholder text. (I might be stretching ‘states’ here!)

This thought popped up when Cliff Tyllick tweeted: "From another participant in @pauljadam's #CSUN16 workshop: Made contrast of placeholder text in forms >3.0:1, and conversion rates dropped.”

There are good usability reasons for both of those items to have ‘low’ contrast. For a button which is disabled it usually needs to be there (otherwise it appears like something is missing), and updating something else on the page will enable it. But it shouldn’t appear active/enabled, which is usually achieved by ‘greying’ it out.
For placeholder text, you don’t want it to appear to be regular text, otherwise people might think that field is already filled in.

-Alastair


From: Katie Haritos-Shea


Thus my reasoning that text in links and controls meet the contrast requirements in all states. It just seems easier than trying to call out one state as being excepted. And who knows what future states may be created as new interaction paradigms.

Katie Haritos-Shea
703-371-5545
On Mar 22, 2016 10:51 AM, "Scott McCormack" wrote:
Hi Andrew, I agree with everything EXCEPT for the point about HOVER for two reasons:


-          When magnification is in use it may not be possible for the user to move the mouse pointer off the control enough to remove the hover effect and still remain readable either because the control has now moved off screen or parts of the mouse pointer are covering the control. This issue is exasperated when controls have a great deal of white space around the text that is included in the hover space requiring the user to move the mouse further away from the text than would otherwise be required.

-          Many low vision users (myself included) use the mouse pointer to follow along when reading text (with or without magnification) like people do with a finger or pen when reading printed materials. This is also very common for magnification user as we will use the mouse pointer to control the magnification view. In such a case a hover with bad contrast would prevent us from being able to read effectively without changing our reading technique.

---
Scott McCormack
Principal Technical Consultant  -- IT Manager
SSB BART Group
scott.mccormack@ssbbartgroup.com<mailto:scott.mccormack@ssbbartgroup.com>
(415)624-2712<tel:%28415%29624-2712> (o)
www.ssbbartgroup.com<http://www.ssbbartgroup.com>

From: Rochford, John [mailto:john.rochford@umassmed.edu<mailto:john.rochford@umassmed.edu>]
Sent: Monday, March 21, 2016 4:35 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>; public-low-vision-a11y-tf@w3.org<mailto:public-low-vision-a11y-tf@w3.org>
Subject: RE: LVTF position on contrast requirements for interactive control states


Hi Andrew,



I agree.

John

John Rochford<http://profiles.umassmed.edu/profiles/display/132901>
UMass Medical School/E.K. Shriver Center
Director, INDEX Program
Instructor, Family Medicine & Community Health
www.DisabilityInfo.org<http://www.DisabilityInfo.org>
Twitter: @ClearHelper<https://twitter.com/clearhelper>



-----Original Message-----
From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: Wednesday, March 16, 2016 4:47 PM
To: public-low-vision-a11y-tf@w3.org<mailto: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<mailto:akirkpat@adobe.com>

http://twitter.com/awkawk


http://blogs.adobe.com/accessibility