-
Notifications
You must be signed in to change notification settings - Fork 266
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
Add hover-related explanatory content to non-text content #3934
Comments
Updated draft: Hover stateThe 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. |
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) |
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. |
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. |
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. |
Catching up with this. It looks good to me. Added a PR for it. |
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.
The text was updated successfully, but these errors were encountered: