[MenuList] Support Home/End keys and wraparound

[eric-parsons]

It would be nice if MenuList supported the optional wraparound for the up/down arrow keyboard navigation as described in the ARIA keyboard navigation guidelines for menus. Same for having the Home/End keys move to the beginning/end of the list.

I'd be happy to submit a PR if this is something the maintainers would want.

• [x ] This is not a v0.x issue.
• [x ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

When the keyboard focus is on any item inside a MenuList:

• Pressing the Home key should move focus to the first item in the list.
• Pressing the End key should move focus to the last item in the list.

When the focus is on the last item in the list, pressing the down arrow should set focus on the first item.

When the focus is on the first item in the list, pressing the up arrow should set focus on the last item in the list.

Current Behavior 😯

Home/End keys have no effect.
Pressing the down arrow when on the last item has no effect.
Pressing the up arrow when on the first item has no effect.

Examples 🌈

https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions.html

Context 🔦

I am developing a WCAG AA-compliant application and want to make the keyboard navigation experience as good as possible for people with accessibility issues, as well as for power users.

[mbrookes]

@eric-parsons I agree with @oliviertassinari - deleting the issue template is a bit selfish. We put it there to make it easier for you to provide the information we need to help solve your issue.

That said, looking at the ARIA guidelines, I think I get where you're going:

Down Arrow:
[...]
When focus is in a menu, moves focus to the next item, optionally wrapping from the last to the first.

@oliviertassinari I'm not big fan, I think wrapping menus are actually bad for accessibility. It was hashed out at some point for Speed Dial, and wrap was abandoned. I don't see the value for menus either, but happy to be convinced otherwise.

[oliviertassinari]

@mbrookes If the wrapping behavior is opt-in and has a small footprint, I see no harm in supporting it.

[eric-parsons]

My apologies. I thought I had accidentally ended up with the bug report template rather than the new feature template. I've updated the original comment with the missing Expected/Current sections. It was an honest mistake, not trying to be "selfish" (I'm offering to contribute after all).

In any case, thanks for having a look. The section in the linked guidelines on Home/End reads as follows:

• Home: If arrow key wrapping is not supported, moves focus to the first item in the current menu or menubar.
• End: If arrow key wrapping is not supported, moves focus to the last item in the current menu or menubar.

This suggests to me that at least one of Home/End or wrapping should be implemented, with the option to implement both.

@mbrookes, can you elaborate on why you think wrapping would be bad for accessibility? The NVDA screen reader for example will read out "x of y" after each option (so the user would know that wraparound occurred), and people with mobility issues might appreciate having to press less keys to navigate. I'm by no means an expert on accessibility though, which is why I'm trying to follow the guidelines.

As far as implementation goes, it would likely be a few extra lines of trivial code.

[oliviertassinari]

As far as implementation goes, it would likely be a few extra lines of trivial code.

Then I have no objection to add the home/end bindings with an opt-in wrapping logic. @mbrookes?

[eps1lon]

@oliviertassinari I'm not big fan, I think wrapping menus are actually bad for accessibility. It was hashed out at some point for Speed Dial, and wrap was abandoned. I don't see the value for menus either, but happy to be convinced otherwise.

Relevant discussion in #12725. I agreed with that only because SpeedDials should not have more than 6 actions (as per guidelines).

Since this is recommended behavior in the WAI-ARIA Authoring Practices I would be in favor of adding that behavior with the ability to opt out.

[oliviertassinari]

with the ability to opt out.

@eps1lon I have benchmarked a lot of alternative UI libs as well as how the browsers and OS handle the problem. It's very inconsistent. So, I think that we should follow the W3C recommendations for the Menu component, having the behavior opt-in by default and the ability to opt-out.

However, I would make one exception for the Select component. The native component doesn't wrap on MacOS nor on Windows. I think that we should opt-out.

I'd be happy to submit a PR if this is something the maintainers would want.

@eric-parsons We would be honored! Also, I want to address #13708 at some point.

[mbrookes]

The NVDA screen reader for example will read out "x of y" after each option (so the user would know that wraparound occurred)

That's good to know. If that's consistent across screen readers, it solves my main concern. It's unfortunate the ARIA guidelines don't tie the recommendations to the resulting UX.

@oliviertassinari 100% for Home / End key support. Wrapping default with opt-out is fine by me.

[eric-parsons]

Thanks everyone for your feedback. I'll get going on a PR then.