Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification over link/button states #157

Closed
awkawk opened this issue Feb 6, 2016 · 28 comments
Closed

Clarification over link/button states #157

awkawk opened this issue Feb 6, 2016 · 28 comments

Comments

@awkawk
Copy link
Member

awkawk commented Feb 6, 2016

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
Copy link
Member

jnurthen commented Feb 9, 2016

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
Copy link
Contributor

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

@alastc
Copy link
Contributor

alastc commented Feb 29, 2016

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
Copy link
Member

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
Copy link
Contributor

@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
Copy link
Member

jnurthen commented Mar 1, 2016

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
Copy link
Contributor

alastc commented Mar 1, 2016

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

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

@jnurthen
Copy link
Member

jnurthen commented Mar 1, 2016

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

@DavidMacDonald
Copy link
Contributor

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

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
Copy link
Contributor

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

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
paul@pauljadam.com

On Mar 1, 2016, at 11:34 AM, David MacDonald notifications@github.com 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
Copy link

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
Copy link
Member Author

awkawk commented Mar 9, 2016

@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
Copy link

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
Copy link
Member Author

awkawk commented Apr 3, 2016

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
Copy link
Member Author

awkawk commented Apr 12, 2016

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
Copy link
Member Author

awkawk commented Apr 14, 2016

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

Needs integration into source docs.

@awkawk
Copy link
Member Author

awkawk commented Apr 15, 2016

Changes suggested in #177

@Aircl0wn
Copy link

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
Copy link
Member

patrickhlauke commented Mar 21, 2023

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

Aircl0wn commented Mar 21, 2023

@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
Copy link
Member

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

@patrickhlauke
Copy link
Member

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

@alastc
Copy link
Contributor

alastc commented May 23, 2023

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.

@alastc alastc added Understanding Old XML docs Needs transfering to the new docs and removed Discussion WCAG 2.2 labels May 23, 2023
@patrickhlauke
Copy link
Member

@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
Copy link
Contributor

fstrr commented Mar 8, 2024

@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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests