fix(container-menu)!: improves logic for returning focus to trigger

[ze-flo]

Description

Improve the logic for returning focus to trigger. Adds optional restoreFocus prop to manager focus return to trigger.

💥 BREAKING CHANGE:

A new restoreFocus prop has been added. By default restoreFocus is true and will return the focus to the trigger on menu item selection, ESC / TAB key press, and clicking outside the menu dropdown. User who need to keep the dropdown open on selection must set restoreFocus={false} and manually handle the focus return.

Detail

• Returning focus to trigger is now executed synchronously before calling the onChange callback. Now, when a menu item triggers Garden's Modal open, the focus will automatically be restored to the menu trigger after the modal has closed.

Screen.Recording.2024-08-29.at.10.19.34.AM.mov

• The focus return logic follows ARIA guidelines set for Actions Menu Button.
• Adds restoreFocus prop which defaults to true. Disabling it gives users more flexibility with managing focus return to the trigger. See demo Story in docs: demo restoreFocus with controlled menu [ DO NOT MERGE! ] #661.

Checklist

• 🌐 demo is up-to-date (npm start)
• 💂‍♂️ includes new unit tests
• ♿ tested for WCAG 2.1 AA compliance
• 📝 tested in Chrome, Firefox, Safari, and Edge

[coveralls]

coverage: 95.786% (+0.07%) from 95.716%
when pulling ac1f4b9 on ze-flo/menu-focus-fix
into ec77a9d on main.

[geotrev]

I like this approach. To reiterate what we discussed, we agreed that deferring trigger focus didn't make sense as consumers can't (and shouldn't) control this behavior anyway. It also leaves room for folks to refocus another element in response to menu closing without affecting screen reader announcements.

[geotrev]

Quick status comment:

Flo and I met offline to go over the current approach and how we can maybe improve focus behavior between controlled and uncontrolled instances of isExpanded. Currently, this PR will only synchronously focus the button if isExpanded is uncontrolled.

Instead, we think there could be an opportunity here to give more direct trigger focus control through the use of a new parameter, which would also slightly change how Menu works in controlled scenarios by requiring consumers to focus their buttons when isExpanded is false.

To-be-discussed at tomorrow's meeting of the minds to get team consensus. 🧐

[geotrev]

I actually think the code below reads better if we use !controlledIsExpanded. I confused nextisExpanded as referring to the next / nested menu state.

awaiting consensus on new direction

[geotrev]

I love how well the new direction cleaned up with the code!

[jzempel]

There was also the general comment about pulling the #661 demo into [patterns]. But if we think the tests are sufficient here to cover that case, then I'm fine (and even more in favor) with that.

[jzempel]

What are the current results of this investigation?

[ze-flo]

The mystery prevails. 🤔

I verified that returnFocusToTrigger is only called once on TAB keypress. ✅

The browser first sets the activeElement to body. Pressing TAB once more sets the focus to the next interactive element. That implies the placement in the tab sequence isn't reset. I created a JIRA task to revisit.