Reach-ui: [MenuButton]: Add lower level API to control state

[CodingDive]

🚀 Feature request

I would love to have more fine grained control of the MenuButton if it does not negatively impact a11y.

Current Behavior

Even though the MenuButton has a render prop to access the internal state, the active state can't be controlled from the outside.

Desired Behavior

Add hooks or props to control the MenuButton. I'm particular interested in ways to

1. show/hide the dropdown
2. opt out of auto focus (or add a way to not focus the drodpown upon activating it programmatically)

This would allow us to initially show the dropdown without the component stealing focus. This could be useful for e.g using @reach/menu-button as a dropdown menu (I'm aware of Combobox) below an <input /> to hint autocompletion suggestions like GitHub offers when typing '@username'.

I think this feature has been requested in a lot of places but I did not find an open issue in this repo.
https://github.com/reach/reach-ui/issues/316
https://spectrum.chat/reach/general/anyway-to-set-the-open-state-on-menu-button~a766702c-0828-454f-aeb6-a73732e8840c

Suggested Solution

Add active prop or hooks to manage the state of the MenuButton.

Describe alternatives you've considered

The only alternative right now seems to be to create some sort of wrapper, wire a ref to the MenuButton to then imperatively .click() the button based on props.
https://spectrum.chat/reach/general/hover-dropdown-implementation-using-menubutton-component-showcase~68d44d8a-9350-4243-9c09-b7d70a73c422

[chaance]

I'm unsure of accessibility implications here. I believe there have been discussions about alternate UIs in the aria practices repo but I'll have to do some reading.

My gut tells me that if you are opening a menu button without a direct click, you may want to reconsider using a menu button.

[CodingDive]

My gut tells me that if you are opening a menu button without a direct click, you may want to reconsider using a menu button.

Two more examples I can think of:

• Persist context menu state and open it after refreshing the page
• Display MenuButton after onContextMenu is fired e.g <div onContextMenu={() => setShowMenuButton()}>Right click me for an accessible dropdown 😍</div>

I really hope there is a way to make this work as I'm also uncertain of the a11y implications with my imperative .click wrapper 🥇

[chaance]

Persist context menu state and open it after refreshing the page

The menu steals and traps focus when it's open (as it should). Refreshing the browser should not send focus into an open menu.

Another problem: if you have multiple menu buttons on a given screen that are controlled by props, you could easily have multiple menus open at a time which we absolutely do not want. How would we trap focus inside two menu portals at once? Unlike a dialog, relying on source order here wouldn't make much sense as there is no visual layering cue that makes it clear which menu is winning the focus war, so to speak.

I'm not saying there are no valid use cases, and indeed we probably want to have a way to support right click menus (though it's worth noting these are not triggered by menu buttons, so it'd be a departure from the current API or possibly a separate component). I am not sure handing over control of the state for this component is the right approach, but I'll leave this open for further discussion.

[CodingDive]

Could reach-ui internally enforce that two MenuButtons can never be open at
the same time?

I think the only way to address the concerns of trapping focus is to be
able to opt out of autofocus when controlling the menu button via props.

When a user clicks on the menu button, no doubt the focus should be on the
first menu item but with props, I feel there will be situations (like the
refresh example) where you'd not want to trap focus and mess with the
natural tab order of the document. In case of the context menu, you'd most
likely have a hidden menu button and always want to trap focus as the
context menu is being activated.

That being said, I haven't studied the aria-spec in depth and have to do
more reading on the topic. Interested in hearing more voices on this 😊

On Sat, Nov 16, 2019, 21:23 Chance Strickland [e-mail]
wrote:

Persist context menu state and open it after refreshing the page

The menu steals and traps focus when it's open (as it should). Refreshing
the browser should not send focus into an open menu.

Another problem: if you have multiple menu buttons on a given screen that
are controlled by props, you could easily have multiple menus open at a
time which we absolutely do not want. How would we trap focus inside two
menu portals at once? Unlike a dialog, relying on source order here
wouldn't make much sense as there is no visual layering cue that makes it
clear which menu is winning the focus war, so to speak.

I'm not saying there are no valid use cases, and indeed we probably want
to have a way to support right clicks if we can't with the current API. I
am just not sure handing over control of the state for this component is
the right approach, but I'll leave this open for further discussion.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/reach/reach-ui/issues/350?email_source=notifications&email_token=AG4BSRZ22M2OIHLGGLDZUN3QUBJENA5CNFSM4JIIY2AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEHZYCY#issuecomment-554671115,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG4BSR63P2XSWHG4OJWGAMLQUBJENANCNFSM4JIIY2AA
.

[chaance]

I think what we'll probably do here is keep MenuButton as is. We'll want a separate package for standalone menu panels – @reach/context-menu perhaps. All the reading I've done confirms my suspicion that a MenuButton's menu should not be controlled by anything other than the button itself. Also not sure how I feel about persistent state since, again, this directly clashes with our focus management which is spelled out in the spec.

[chaance]

This could be useful for e.g using @reach/menu-button as a dropdown menu

I would seriously encourage you not to do this. A dropdown is a listbox as far as aria roles are concerned, and they have different behaviors. The number one goal of this project is to build a more accessible web, but that point is lost if developers misuse the tools we give them.

We can and probably should do a better job on explaining this distinction with menu button vs. listbox. FYI, we are working on a listbox package that will likely be better suited for your needs here.