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

Buttons navigation hover state needs more contrast #132

Closed
ryelle opened this issue Apr 5, 2024 · 9 comments
Closed

Buttons navigation hover state needs more contrast #132

ryelle opened this issue Apr 5, 2024 · 9 comments
Labels
Accessibility Issues related to keyboard navigation, screen readers, etc [Component] Blocks [Status] Needs Design

Comments

@ryelle
Copy link
Contributor

ryelle commented Apr 5, 2024

any visual information necessary to indicate state, such as whether a component is selected or focused must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio.

1.4.11 Non-text Contrast

I understand this to mean that the hover state should have a 3:1 contrast ratio from the default state, to indicate which item is hovered, since these are all links in a row. Currently the hover state only changes the background from white to light grey, a contrast of 1.08.

Screenshot 2024-04-05 at 12 07 58 PM

Maybe as simple as changing the link color to blueberry? Although blueberry-1/charcoal-1's contrast is just shy, at 2.97. 🤔

Screenshot 2024-04-05 at 11 30 33 AM

@WordPress/meta-design What do you think?

@ryelle
Copy link
Contributor Author

ryelle commented Apr 5, 2024

I think underlining the link on hover would also suffice, we could leave the current colors alone in that case.

@StevenDufresne
Copy link
Contributor

What about using the same idea as the focus state but in black with a white border inset? That could also solve #131.

1px inset
Screenshot 2024-04-08 at 11 06 03 AM

2px inset

Screenshot 2024-04-08 at 11 04 10 AM

@jasmussen
Copy link

I'd lean to underlining on hover.

However, it was not my impression that the hover style needed to pass any contrast ratios at all, since that state is entirely decorative.

This Success Criterion does not require that changes in color that differentiate between states of an individual component meet the 3:1 contrast ratio when they do not appear next to each other. For example, there is not a new requirement that visited links contrast with the default color, or that mouse hover indicators contrast with the default state. However, the component must not lose contrast with the adjacent colors, and non-text indicators such as the check in a checkbox, or an arrow graphic indicating a menu is selected or open must have sufficient contrast to the adjacent colors.

Outside of any nuance I'm missing, the hover states were intentionally designed to be just those light gray colors, because they do not need to meet ratios. So if that's the case after all, I would not make any changes.

@ryelle
Copy link
Contributor Author

ryelle commented Apr 8, 2024

There's a lot of double-negative in that statement, so if I flip around that first line, what I understand is:

This Success Criterion requires that changes in color that differentiate between states of an individual component meet the 3:1 contrast ratio when they appear next to each other.

In other words, we have multiple nav items next to each other, so the change in state needs to be visible between elements, and "hover" is a different state.

That said, this comment suggests that the mouse pointer changing would be enough of a non-color change to count, so maybe we're all good. The focus state already passes by using an outline.

If we're okay with underlining on hover, I think that would be clearly passing this criteria, but we could probably squeak by with the cursor change.

@jasmussen
Copy link

It's an option, but I'd love to design proactively based on a full understanding rather than a half understanding, so unless we're sure I'd lean towards not adding the underline. This is to ensure we're synced up with any other button hover states, etc. Alternately we can remove the hover state entirely.

@ryelle ryelle added the Accessibility Issues related to keyboard navigation, screen readers, etc label Apr 8, 2024
@ryelle
Copy link
Contributor Author

ryelle commented Apr 8, 2024

Clearly my tone got in my own way here— we're fine with just the cursor change, so we can stick with that, though I still think an underline would be more obvious, and we do already have the pattern of underlines in nav menus.

@jasmussen
Copy link

Good point on the nav menus 👍 👍, happy to add the underline as part of bringing consistency with that. I know @fcoveram worked on these, just for a gut check.

@fcoveram
Copy link

I'm drawn to change the cursor.

Menu links take you to a different page and behave visually to standard links to move between pages, whereas this button belongs to a family of actions that apply content changes on the same page. Adding an underline in hover would look odd if we don't add it to the whole set.

@ryelle
Copy link
Contributor Author

ryelle commented Apr 11, 2024

Speaking technically, these category links are also a menu of links taking you to a new page, but I understand you mean conceptually. The cursor already changes, so we can just leave it at that unless we get specific feedback later. I'll close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accessibility Issues related to keyboard navigation, screen readers, etc [Component] Blocks [Status] Needs Design
Projects
None yet
Development

No branches or pull requests

4 participants