Hover-based menus that are problematic for users with low dexterity - covered by 2.5.1 Pointer Gestures? #3839
Replies: 4 comments
-
and to be clear, assuming the menu/submenu is built to pass 1.4.13 Content on Hover or Focus |
Beta Was this translation helpful? Give feedback.
-
IMHO, no, the trigger is whether the pointer is over a particular area of content, not whether the user does a gesture. Sorry... |
Beta Was this translation helpful? Give feedback.
-
there's a further deimension for keyboard only users in that these kidns of menus can only be navigated by tabbing which, for some implementations, can require considerable effort to reach items buried deep within the menu dropdowns ... not really a pointer gesture issue, but something to consider for future specifications? That is, under something like 2.4.3 in which 'preserves operability' means 'don't make me tab more than x number of times in a hover menu because it is frustrating/painful/unnecessary'. |
Beta Was this translation helpful? Give feedback.
-
This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list. |
Beta Was this translation helpful? Give feedback.
-
I think the answer is currently "no", but checking anyway: assume there's a menu with submenus, and it currently works (for pointer users) only using hover. As soon as the pointer strays out of the menu/submenu, the whole menu closes. For users with low dexterity, this menu can be hard to navigate/use without accidentally closing it. By the letter of 2.5.1, this is likely not covered, though there's a slightly (overstretched) way of interpreting this interaction as being "path-based" in that users can't stray from the menu/submenu.
If it's not covered by 2.5.1, does this sound like a gap to address (in future)?
Beta Was this translation helpful? Give feedback.
All reactions