Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#48471 closed enhancement (duplicate)

Change hover behavior for profile menu item

Reported by: sjnbham's profile sjnbham Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Toolbar Keywords:
Focuses: ui, accessibility Cc:

Description

It would be great to change the behavior from hover to click for the profile menu to expand on the top admin toolbar. When moving a mouse to the top right of the screen to click the Update button for a post or page, more than half the time I accidentally hover over the profile link which then overlaps the update button and then I click. This results in a dialogue box being displayed asking if I want to leave the site and changes may not be saved. This seems like a minor annoyance, but I’ll bet there are many others out there that experience the same thing. Also, the profile/logout link is so rarely used by our content editors, the difference between two clicks vs. hover and click isn’t a big deal.

Another way to address this could be to provide an option to universally have menus expand and collapse only on click vs. hover in the admin interface. It may also have the side affect of making it a bit more accessible for those with poor motor skills.

Change History (14)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Toolbar

#2 @johnbillion
5 years ago

  • Keywords needs-design-feedback added

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 years ago

#4 @morgandruscarr
5 years ago

  • Keywords needs-design added

#5 @lonnietapia
5 years ago

Tagging "needs design" so we can see option 1 before implementing anything.

#6 @lonnietapia
5 years ago

@sjnbham The second option could also be a separate ticket. Would you consider opening one just for that?

#7 @sjnbham
5 years ago

@lonnietapia - created separate ticket for all admin toolbar links: #48494

Thanks

Last edited 5 years ago by SergeyBiryukov (previous) (diff)

#8 @dinhtungdu
5 years ago

IMO, we can fix this issue by increasing the interval of hoverIntent which is 100 currently.
Also, changing the default behavior from hover to click can be very dangerous because Toolbar has been using hover for years, changing it means educating end-users again.

Version 0, edited 5 years ago by dinhtungdu (next)

#9 @sjnbham
5 years ago

Thanks for the suggestion @dinhtungdu

I tried increasing the hoverintent setting. While it does help with the accidental mouseovers, it creates a different problem. When someone mouses over it, the delay in having the submenu open will likely lead to people trying to click on the parent link anyway.

I understand the hover has been the convention for a long time. The click is more accessible all around though and users would adjust quickly as click to open menus is a common interface convention.

https://www.liquidlight.co.uk/blog/navigation-drop-downs-should-they-be-hover-or-click/

Last edited 5 years ago by sjnbham (previous) (diff)

#10 @afercia
5 years ago

Related: #34668 (which highlighted the need for some refactoring of the entire hover / click mechanism of the admin top bar)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 years ago

#12 @afercia
5 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Severity changed from trivial to normal

Discussed during today's accessibility bug-scrub and agreed to set it to Future Release as "accepted" for now, same as the related #34668.

#14 @afercia
5 years ago

  • Keywords needs-design-feedback needs-design removed
  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version 5.2.4 deleted

Noting that #48894 focuses on the same issue and it's currently milestoned for WordPress 5.5. Although, technically, #48894 is a duplicate ticket, it has more feedback and an initial patch so it's probably best to close this ticket in favor of #48894. Apologies for the confusion. Please do feel free to join the ongoing progress on #48894.

Note: See TracTickets for help on using tickets.