Reach-ui: Add ability to keep MenuList open after `onSelect` calls

[kylemh]

🚀 Feature request

Current Behavior

When clicking or selecting an item from the MenuList in a Menu, the MenuList unrenders and returns focus to the MenuButton

Desired Behavior

I have the ability to control if a MenuItem or MenuLink's selection actually collapses the MenuList.

Suggested Solution

I definitely understand the need to give back correct focus state. A developer-friendly ergonomic that still encourages/enforces accessibility could occur by simply having the existence of some MenuCloseButton. Essentially, if that element type exists, the onSelect callbacks attached to MenuItems and MenuLinks wont close the MenuList, but there's still definitely a specific and required means to close the menu and return focus.

Who does this impact? Who is this for?

My use case is a MenuList of options that help filter a list. It's not an ideal user experience for people to re-open the Menu every time they want to select an item in our situation because it acts as a sort of checkbox list.

Describe alternatives you've considered

In reality, this should probably be a form with a submit button, but...

• I could use a Checkbox components and make the last (and only) MenuButton a type="submit" button, but I worry about how this communicates outwards to keyboard-only users. If this is viable, I'd like to add documentation regarding this. I'm also not sure how I'd tell the Menu to collapse on submit for people that would key Enter before reaching the submit button.
• I can't use ListBox because it doesn't support multiple selections
• I don't want to hand-roll my own component, because ReachUI handles so much for me already!

[cpmsmith]

• I can't use ListBox because it doesn't support multiple selections

It looks like Listbox is supposed to be the component to cover this use-case, according to the WAI-ARIA spec:

A listbox widget presents a list of options and allows a user to select one or more of them. A listbox that allows a single option to be chosen is a single-select listbox; one that allows multiple options to be selected is a multi-select listbox.

The issue here, then, is that Reach hasn't implemented that part.

[chaance]

@cpmsmith is correct AFAICT. We may decide to implement a multi-select listbox down the road but for now it's probably out of scope. If you want to fork our existing listbox and follow and open a PR, I'm happy to consider it. As of now I'm focused on improvements and bug fixes as I don't have the bandwidth for spinning up new features right now.

[kylemh]

@chancestrickland can we leave this issue open then? I'll eventually contribute the implementation outlined by @cpmsmith