w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.06k stars 232 forks source link

Add hover-related explanatory content to non-text content #3934

Open fstrr opened 2 weeks ago

fstrr commented 2 weeks ago

As discussed in this week's backlog meeting, non-text contrast could benefit from content explaining the rational around hover states.

@mbgower volunteered to create this.

mbgower commented 1 week ago

Updated draft:

Hover state

The language of Non-text Contrast specifically calls out "visual information required to identify...states." When users talk about a hover state, they are normally referring to a visual effect that takes place when the pointer is positioned over a control. However, there are a number of HTML components (such as buttons, checkboxes, radio buttons, and selects) which do not by default display any additional visual effects when the user moves a pointer control over them. The pointer itself, via its location, is the indicator of whether the user is hovering on a component. Therefore, additional author-supplied visual treatments for hover are not "required to identify" the hover state. Those treatments can be considered supplemental and do not themselves need to contrast 3:1 against the background.

This is not to say that other hover effects are discouraged. For instance, some native components alter the shape of the pointer when it is hovering over a control; the pointer becomes an I-beam when it hovers over text inputs and text areas. There will be cases where some users may benefit from additional visual hover effects, such as bolding text or use of drop shadows. However, other users may find strong hover effects distracting. The key consideration for any hover effect is that it does not cause a component itself to lose sufficient contrast against adjacent colors, or cause the visual indicators for other states, such as focus or selection, to lose sufficient contrast.

patrickhlauke commented 1 week ago

Since the pointer by default is black with a white outline, the shape will always meet contrast minimum regardless of the page background

It may be dangerous to start talking about the pointer here, as that's an aspect of the OS/user agent unless an author has explicitly suppressed the pointer / replaced it with a custom image or indicator.

I'd say instead of talking about whether it's black/white, expand on this to say that unless the author has modified it, the pointer is not under the author's control, so exempt from the SC (as at that point it's not "web content" per se)

mbgower commented 1 week ago

I removed the 4th sentence "Since the pointer by default is black with a white outline, the shape will always meet contrast minimum regardless of the page background." I think its removal is likely sufficient, and we do not need to go into a discussion on pointer modifications, etc.

I also added in mention of two common author-supplied hover effects in the second paragraph.

fstrr commented 1 week ago

Is there a way in GitHub to get a diff of two specific versions of a comment? I accidentally discovered that if you highlight all the text in a comment and then click on "edited", it gives you a diff between that and what looks like the previous edit, but I can't find a way to get it to show a diff from the current edit to the first one.

mbgower commented 1 week ago

Is there a way in GitHub to get a diff of two specific versions of a comment?

No idea, but I literally made no other changes except the two that I listed (even if I made a number of commits to arrive at those changes). My intent was obviously to do this as a PR so we'd be able to make suggests/commits with gay abandon, but my 1-paragraph change resulted in the reformatting of every line in the file. Feel free to create a PR yourself, if you can make it cleanly.

fstrr commented 1 week ago

Catching up with this. It looks good to me. Added a PR for it.