Clarification over link/button states

[awkawk]

Name: Jim Osborn
Email: (removed)
Affiliation:
Document: UW
Item Number: Understanding Success Criterion 1.4.3
Comment (Including rationale for any proposed change):
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.

Likewise, if the above is an incorrect assumption then a note could clarify the requirements.

Proposed Change:
Add a new note (similar to note 3) to clarify if contrast success criterion for 1.4.3 applies to all states for interactive elements such as links, buttons and inputs.

For example:
"Note 4: Different interactive states (e.g. the focus state of a button) must also provide sufficient contrast to satisfy the minimum contrast success criterion (1.4.3)."

[jnurthen]

We should probably exclude transient states from this. For example a button goes into the :active state when it is being pressed. IMO it is not necessary that its text content need be read when it is in this state as it is only like this for a short amount of time.

[joshueoconnor]

I'm inclined to agree with @jnurthen on this. Do we need to change this SC so contrast requirements cover all states?

[alastc]

I'm not sure about the transient states, for example, I observed a low-vision user in usability testing who was using a magnifier. He was zoomed in to around 800%, and when he moused-over a link, it became pink on white. Quite clear to me, but I found out later his vision struggled with colours like pink & orange on white. From his point of view it disappeared, which was quite disconcerting.
It wasn't a complete dead end, after a few goes he did continue, so I wouldn't object to excluding transient states, but I would ask if anyone else has seen more difficult examples.

[jnurthen]

By transient states I didn't mean the focus/hover state. I agree that those need to be readable (except ironically on touch where generally no one can read those states as the finger is over the control).

I was talking about states which happen for only a really short amount of time like those when actually pressing a button.

[greg-lowney]

@jnurthen, I don’t agree with your parenthetical exception: I rely heavily on focus/hover feedback when using mobile devices in order to reduce the number of wrong buttons pushed, especially when they’re closely spaced, and for realizing that the wrong button was pressed without having to switch my gaze to see the results. While my finger may obscure the glyph on an on-screen key I'm pressing, enough of its face is visible to make its color change obvious. I’m not convinced it’s less necessary for those with additional visual impairments.

I also worry about whether we can create criteria to objectively differentiate between “transient” events that don’t need to be conveyed and others that do.

[jnurthen]

But can you read the text on it when your finger is over it? That is what 1.4.3 is about. As far as I'm aware there is nothing in 1.4.3 which requires any focus/hover feedback at all.

(Note - i am not saying we shouldn't do this as, like you, I believe it is valuable. I just don't think wcag requires it)

[alastc]

@jnurthen ah, well if you mean really transient then I agree :-)

However, I would have assumed focus/hover would classify as "transient".

[jnurthen]

@alastc yeah - just couldn't come up with a good word for what I meant :)

[DavidMacDonald]

WCAG requires all displayed text to have minimum contrast except for logos and inactive text.... a hover state is active in its hover state as is all other transient text, so it has to meet minimums. we don't have a time limit... perhaps we should be we don't currently ... I think for REALLY transient stuff most evaluators let it slide, even though there isn't an explicit exception in WCAG... technically we can't change WCAG but we could possibly say "we really intended that this no cover quick transition effects.

Perhaps we can say something like
"1.4.3 is not intended to apply to transition effects which have a fixed transition time of less than a second."

Or 2 or 3 seconds....
that would exclude hover states which are variable in length...

[MakotoUeki]

I got the Working Group's response on this issue 2 years ago.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html

Is the requirement of SC 1.4.3/1.4.6 changing to cover all states?

[DavidMacDonald]

That response is not my reading of WCAG, but I think we have to honour a vetted group response... I must not have been on that call...

[pauljadam]

This is also my reading of WCAG’s Contrast requirement. It says text except for logos and disabled controls needs to meet contrast requirements.

How is it accessible if the button text turns into a very low contrast color when I hover over it or tab to it? I did not see any exception for hover states or focus states of text.

Paul J. Adam
[email protected]

On Mar 1, 2016, at 11:34 AM, David MacDonald [email protected] wrote:

WCAG requires all displayed text to have minimum contrast except for logos and inactive text.... a hover stat is active in its hove state as is all other transient text. we don't have a time limit... perhaps we should be we don't currently ...

—
Reply to this email directly or view it on GitHub #157 (comment).

[MakotoUeki]

I used to understand this SC in the same way. After I got the response from the WG, I've been encouraging my clients to cover hover/focus states as the best practice. So I welcome this change :-)

[awkawk]

@DavidMacDonald you were on that call. https://www.w3.org/2014/02/18-wai-wcag-minutes.html We agreed that it wasn't strictly required and that we would add it to the list for future clarification.

[MakotoUeki]

If the WG will change the interpretation from the response I got 2 years ago, I'd like the WG to explain the rationale in Understanding document. This is a big change to be explained.
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast7.html

[awkawk]

The LVTF considered this issue and offers the following response:

It is recommended that the text of links and controls which changes in response to focus and hover events meets the appropriate contrast requirement in WCAG 2.0 Success Criteria 1.4.3. Both hover and focus states impact low-vision users:

• Focus: Low-vision keyboard users may be unable to read low-contrast text on a focused control and due to page magnification may be unable to simply tab away from a focused control and keep that control in view on the screen.
• Hover: Many low vision users 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 very common for magnification users who will use the mouse pointer to control the magnification view area. In such a case a hover with bad contrast prevents users from being able to read effectively.

[awkawk]

The WCAG Group met on April 12, 2016 (http://www.w3.org/2016/04/12-wai-wcag-minutes.html) and arrived at the following resolution (to be approved by CfC process):

The WCAG WG interprets Success Criteria 1.4.3 to require that the text of links and controls which change in response to focus and hover events meets the appropriate contrast requirement.

This is a change from the previous interpretation offered by the working group as a result of input from the Low Vision Task Force which identified additional concerns that the working group had not considered, and which are addressed below.

Both hover and focus states impact low-vision users, but the active state (the typically split-second state when a button or control is being clicked or pressed) is not explicitly required to meet the contrast requirement.

Focus: Low-vision keyboard users may be unable to read low-contrast text on a focused control and due to page magnification may be unable to simply tab away from a focused control and keep that control in view on the screen.
Hover: Many low vision users 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 very common for magnification users who will use the mouse pointer to control the magnification view area. In such a case a hover with bad contrast prevents users from being able to read effectively.

[awkawk]

CfC passed: https://lists.w3.org/Archives/Public/w3c-wai-gl/2016AprJun/0149.html

Needs integration into source docs.

[awkawk]

Changes suggested in #177

[Aircl0wn]

Based on a recent discussion this issues popped up. Seems like @awkawk wrote an update for the UD to clarify this decision. All got approved, but the working branch never got merged in further up stream?

[patrickhlauke]

Looking at this properly after my initial confusion, yes it seems the old .xml file was updated in #177, merged into Working-Branch-for-Q3-2016 ... but then never made it to the actual main branch

[Aircl0wn]

@patrickhlauke Think you're right in the sense that they did get merged. The text from the change is the current UD text. My bad for not reading the change correctly.

The change, however, does don't reflect the decision that text contrast in focus and hover states should be taken into account for this.

[patrickhlauke]

I know, I'm only confirming what you said ... it never made it further up stream from that working branch for Q3.

[patrickhlauke]

@awkawk @alastc any scope to reopen this/rework it?

[alastc]

If someone can review the previous change and apply that to the newer file, then we can check if newer changes since then have confused it.

If not, then it's an already agreed thing and can be merged. If there are some conflicts, we can send it around for review.

I'll remove the WCAG 2.2 label (as it is not a WCAG 2.2 SC), but if you tag it with "Survey - Ready for" it will go into the queue for review.

[patrickhlauke]

@Aircl0wn @alastc actually...looking at this in more detail, it seems that the core part of this, the addition of an explicit mention of focus/hover, was indeed added at some point. I must have missed it because some of the other reorderings/changes in #177 have since been morphed/changed/reorganised.

in short, the understanding for 1.4.3 includes the following

The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast.

so this issue can remain closed.

I see though than in my recent #3020 I actually accidentally copied the above also into 1.4.6, verbatim, which makes no sense. Just filed a small follow-up tweak (as it looks odd that the 1.4.6 understanding mentions that 1.4.3 (!) applies to focus/hover, when it really means "This SC". see #3216

[fstrr]

@patrickhlauke In your last comment, I think you're suggesting this can be closed. If it can, that's great; if not, I'll add it to the backlog board.

[patrickhlauke]

@fstrr ah yes, this can be closed now that #3216 is merged