Menu hover state missing, or impossibly hard to see

[JJJ]

Describe the bug
There is a severe lack of contrast on the hover state of the vertical ellipsis menu.

To Reproduce
Steps to reproduce the behavior:

1. Compose a new post
2. Click on the vertical ellipsis button to expose the drop-down menu
3. Hover over a menu item
4. Try to tell which item is being hovered over

Expected behavior
I expect some visual indication that a menu item is being hovered over with a mouse.

Screenshots

Desktop (please complete the following information):

• OS: any
• Browser: any
• Version: latest

Additional context

• WordPress 5.0 RC 1

[Mariyan96]

From designer point of view, this is probably not an issue, though I would like to hear other designer's opinions on this as it might change the overall appearance for hover effects :)

[designsimply]

Tested and confirmed with 4.5.1 master @ e4fd51cb5 that hovered menu items only receive a very slight color change.

^{Seen at http://localhost:8888/wp-admin/post.php?post=501&action=edit running WordPress 4.9.8 and Gutenberg 4.5.1 master @ e4fd51cb5 using Firefox 63.0.3 on macOS 10.13.6.}

[mapk]

I'd also like to know if this is an a11y problem. @LukePettway can you provide some insight here?

[afercia]

Discussed during today's accessibility bug scrub. Worth considering a clear indication of the hover state is important for some users and the cursor shape is not sufficient.

One of the most obvious options would be to make the focus and hover styles the same. Worth considering the Customizer does that, as it introduced some releases ago a new pattern with a "left border":

This is also what we (as accessibility team) are recommending for the admin menu in the (long pending) Trac ticket https://core.trac.wordpress.org/ticket/28599

Some consistent pattern across WordPress would be nice :)

[m-e-h]

From what I can tell, there currently is a hover effect on medium+ size screens. For some reason this is wrapped in a media query...

@media (min-width:782px) {
	.components-menu-item__button.components-icon-button:hover:not(:disabled):not([aria-disabled=true]),
	.components-menu-item__button:hover:not(:disabled):not([aria-disabled=true]) {
		color:#191e23;
		border:none;
		box-shadow:none;
		background:#f3f4f5
	}
}

I guess this is the reason #10333
I don't really understand it though. Surely there's a better solution.

[mapk]

Testing this, I see a hover state for desktop but when I switch my browser to responsive view, I get the very subtle text fade on mobile screen sizes. I assume this is due to mobile devices not needing a hover state.

[m-e-h]

So I'm thinking, at some point after this gh issue, the hover effect was implemented without knowing about this gh issue?

I assume this is due to mobile devices not needing a hover state.

That probably is why the hover was removed for screens smaller than 782px.
But I think that might remove the hover for some maybe not so edge cases.

There are a couple media queries we can use to cover some of those "smaller screen + mouse" users.

The safest I think would be something like this:

@include break-medium() {
	@include menu-style__hover;
}

@media (hover: hover) {
	@include menu-style__hover;
}

That would cover screens larger than the medium breakpoint and then also screens that might be smaller but whose primary input method is capable of hovering.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover

The browser support is surprisingly solid for how little known these MQs are.

Some others that might also work:
@media (pointer: fine)
@media (any-hover: hover)
@media (any-pointer: fine)

What are your thoughts on this @jasmussen ?

[afercia]

I assume this is due to mobile devices not needing a hover state.

Worth noting that assuming a CSS media breakpoint triggers exclusively on mobile devices is misleading. For example, users with vision impairments may use high zoom levels in the browser. Depending also on the screen, at a 200% zoom level (or slightly more) the "responsive view" may kick in. In this scenario, users still need hover states.

[mapk]

Based on Andrea's comment, can we just include the hover state... always? Are there any arguments against going this route?

[m-e-h]

#10333 is why it was originally removed for mobile.

Just reading that issue, I don't think it justifies removing the hover state. But I've never actually seen the issue on iOS so I don't know how bad it is.

I'll try to play around with it tomorrow.