Menu pattern: moving focus on hover often triggers problematic focus jumps

[smhigley]

Related to #598

Related to this guidance on the Editor Menubar example in the APG:

When a submenu is open and the user hovers over an item in the submenu, focus follows hover.

Reading through past issues, it looks like this was largely added for parity with desktop behavior rather than for any specific accessibility benefit on its own merit. The problem is that it also isn't neutral -- this guidance can cause some pretty unfortunate glitchy focus jumps that I think outweigh any potential benefit of strictly copying desktop behavior.

There are two scenarios that cause issues:

1. When the mouse is positioned somewhere within the menu and the menu has scroll overflow, every time keyboard arrowing triggers scroll, focus will jump back up under the mouse cursor. Here is a reduced case demonstrating this bug: https://codepen.io/smhigley/full/ZYEGeLO.

   There is a more involved way to implement this that would not trigger focus just based on the item scrolling under the mouse cursor using the mousemove event, but it is both less likely to be implemented that way, and when it is, the menu is even more prone to stealing focus at the slightest mouse bump or tremor (see the next point)

2. When the mouse is positioned somewhere within the menu and the user brushes their hand against a trackpad or bumps their mouse, focus will jump.

Both these issues are even more likely to happen if the user has their mouse cursor move when a control is activated, which would automatically pull the cursor up to the menu when it is opened, making it more likely to hover over a menuitem.

While I do agree with the guidance that mouse hover essentially needs to move focus when it causes the currently focused menu to close and a new one to open, I think the second point about hover always moving focus within an open menu should be reconsidered. I'm not sure there's really any benefit to doing so other than the nebulous "copy desktop patterns" idea, which I don't believe should carry more weight than avoiding harmful behaviors.

What do other folks think? Are there any UX benefits to having focus follow hover that I'm missing?

[aardrian]

A few years ago I was performing user research with a financial institution which tested a pattern as described (focus follows mouse pointer) in its web site (the non-marketing site).

We found participants who used keyboard navigation were generally frustrated that focus jumped when using their keyboard and did not understand why. The example above is a good analogue to the pattern that caused users frustration.

The client removed it and follow-up participants raised no complaints about its absence.

In a web context I agree the behavior of having focus follow the mouse pointer can be counter-intuitive.

[mcking65]

@smhigley

Reading through #598, I thought we eliminated movement of focus on hover. Is that text in the editor menubar example out of date, or is it really moving focus on hover?

I agree 100% that moving focus on hover is a big problem. I frequently have to move my mouse to a corner of the screen to get rid of these negative side effects. It took a long time to learn that trick, and I fear that many screen reader users have no idea when they are experiencing unexpected focus change problems due to hover. This is a big problem in many popular products.

While APG avoids the infinite rabitt hole of documenting antipatterns, it does seem that there is some positive guidance that could be included in both the pattern and examples to help people prevent these negative side effects. Do you have a specific suggestion?

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3238 - Hover moving focus in menus.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3238 - Hover moving focus in menus
<jugglinmike> github: https://github.com//issues/3238#issuecomment-2661124672
<jugglinmike> sarah4: Application menus on Windows (and maybe macOS) have focus follow hover when they're open
<jugglinmike> sarah4: The editor menu example in the APG does that same thing. When you have an open dropdown menu, focus follows hover
<jugglinmike> sarah4: That happens in the script, and there's a line in the guidance that describes that behavior
<jugglinmike> sarah4: Because of this, we did the same behavior in my library that I work on. We've had a number of problems since making that decision (especially when there's scroll overflow)
<jugglinmike> sarah4: I'm not sure what the benefit is of focus following hover--other than that Windows and macOS do it
<jugglinmike> sarah4: I'm wondering if there's a benefit beyond matching native OS
<jugglinmike> Matt_King: One thing that happens to me is, when I'm using Google Docs, and I press alt+shift+A to open the accessibility menu--if my mouse happens to be sitting in the area that that menu pops open to (so that the mouse ends up being somewhere in the middle of the menu), then the comments item automatically gets activated, and I end up in a sub-menu of the accessibility menu.
<jugglinmike> sarah4: Yeah, that's another example of what I'm talking about
<jugglinmike> Matt_King: If weird stuff like that is happening, I go through an exercise to park my mouse in a corner of the screen, and the problem goes away
<jugglinmike> Matt_King: Freedom Scientific was talking about making that behavior happen automatically--they just have to do so without disrupting mouse users
<jugglinmike> sarah4: It makes me sad that the workaround is "move the mouse"
<jugglinmike> Matt_King: I thought we made it so that you had to click, so that we weren't ever moving focus unless you clicked
<jugglinmike> sarah4: I went back and read all the discussions. On the editor menu bar (not in the dropdown menus), focus doesn't follow the mouse before you've opened anything. As soon as you open something, it will follow
<jugglinmike> Matt_King: Ah, so that's why it applies to my case. If you open with the keyboard, and the mouse is in place, then boom
<jugglinmike> sarah4: Right
<jugglinmike> Matt_King: Let's say someone clicks on the first drop down, and that opens the first dropdown, but then they move their mouse to hover over the second item in the top menu bar. They are expecting to see the items in that menu to be automatically displayed...
<jugglinmike> Matt_King: If focus moved when they did that first click, but then wasn't moving as they hovered over the second, third, fourth items in the menu bar--does that have any negative side-effects? If the focus doesn't move?
<jugglinmike> sarah4: I think we could still handle focus if, with your mouse, you close
<Jem> editor menu bar example link https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-editor/
<jugglinmike> sarah4: I think we could do a focus-recovery thing with more nuanced heuristics (without having focus always follow hover)
<jugglinmike> Matt_King: Do all the negative side-effects of this occur when somebody isn't actually moving the mouse?
<jugglinmike> sarah4: Yes. I can reproduce this in the example right now: I put my mouse underneath the dropdown, then use the keyboard to open the dropdown, and focus jumps to the location of my mouse
<jugglinmike> Matt_King: If someone is driving their magnifier with their mouse, and they also use the keyboard--that is a case where you also want focus to move, right?
<jugglinmike> sarah4: I don't think so. I believe with something like zoom text, it will follow focus of the keyboard
<jugglinmike> sarah4: I don't think Zoom Text needs our help
<jugglinmike> Matt_King: If it's always related to side-effects of the mouse being static, I wonder if there's a really simple approach.
<jugglinmike> Matt_King: If there's no mouse movement...
<jugglinmike> sarah4: We did that--we switched to using "mousemove". The side effect of that, is that if your mouse is just resting, then focus won't immediately jump, but if you just brush your touchpad or bump your mouse...
<jugglinmike> Matt_King: Oooh, right. I disable the touchpad for this reason
<jugglinmike> Matt_King: We recently landed a pull request that addressed this, partially at least, on one example. I think it was on one of the "action menu button" examples, but I'm not sure
<jugglinmike> Matt_King: What you're talking about here is more like the guidance. I feel like we should update the guidance and then use that to raise bugs against the examples
<jugglinmike> Matt_King: Is there anybody that has any objection to removing automatically having focus follow hover?
<jugglinmike> Jem: It sounds like removing that would be a straightforward solution for now
<jugglinmike> Matt_King: We don't have any accessibility for keeping this capability of having focus follow hover, right?
<jugglinmike> Matt_King: Hearing none, I think that answer's sarah4's most fundamental question
<jugglinmike> sarah4: Excellent. I can even open the pull request to make this change
<jugglinmike> Matt_King: Awesome
<jugglinmike> Zakim, end the meeting

[mcking65]

When reviewing #2975, I added a comment related to a problem of this nature.

In response, @jongund pushed cb05d80 and replied:

I fixed the issue with focus moving to the menu item the mouse is hovering on in chrome by removing a pointerover event handler. I check our other menu examples and they are not using this event, so our existing examples should be good.

@smhigley

From your feedback, I assume that just looking for use of pointerover is insufficient and that we can create these problems in other ways.