Accessibility: Move focus back to the modal dialog to More Menu when it was used to get there

[gziolo]

Description

Related: #15321 (it's probably the fix).

When the "Keyboard Shortcuts" and "Options" dialogs are dismissed,
the keyboard focus is reset to the top of the page. This may be
confusing or inconvenient for users, who would expect the focus to
return to the last element they were focused on.

This PR changes the behavior of More Menu in terms of maintaining focus. When a dialog is opened from one of the menu items, then we no longer close More Menu. Instead, we keep it opened and move focus back to the More Menu when the dialog is closed.

Known issue

When I mouse-click outside of the modal dialog then More Menu remains opened. This is because Modal dialog prevents all events to be propagated below the overlay layer. We need to find a fix for it, @youknowriad any hints? - this is resolved now

How has this been tested?

1. Open More Menu.
2. Click on the Block Manager menu item (or anything else).
3. Close the dialog by clicking on the close button.
4. Focus should return to the item in More Menu.
5. Repeat steps 2-4 but this time click outside of the modal dialog instead..
6. Repeat using keyboard-only navigation (space to select an item and esc to close the dialog.

See also the screencast.

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

I have no idea whether we can assume that focus can be moved to the element with [role="dialog"] in all cases. Thoughts?

[talldan]

It definitely feels like there needs to be a more general way to track that a modal or popover was opened from the context of another modal or popover, and exclude it from the focus outside check.

There's a similar issue here with the inline link popover, where it needs to check whether focus is in the autocomplete list to avoid closing:

gutenberg/packages/format-library/src/link/inline.js

Lines 168 to 179 in fb910e5

	onFocusOutside() {
	// The autocomplete suggestions list renders in a separate popover (in a portal),
	// so onFocusOutside fails to detect that a click on a suggestion occurred in the
	// LinkContainer. Detect clicks on autocomplete suggestions using a ref here, and
	// return to avoid the popover being closed.
	const autocompleteElement = this.autocompleteRef.current;
	if ( autocompleteElement && autocompleteElement.contains( document.activeElement ) ) {
	return;
	}
	this.resetState();
	}

Having said that, I can't think of a case where this logic fails, so I think it'd be pragmatic to ship this, and then consider what a more general solution might be.

[gziolo]

When I mouse-click outside of the modal dialog then More Menu remains opened. This is because Modal dialog prevents all events to be propagated below the overlay layer. We need to find a fix for it, @youknowriad any hints?

This is exactly how More Menu stays wrongly opened:

[afercia]

@afercia - do we have an open issue for this or did we talk about it only in comments on other PRs/issues?

@gziolo Besides mentions in other PRs/issues, I think #15321 is very specific to this problem.

[gziolo]

@gziolo Besides mentions in other PRs/issues, I think #15321 is very specific to this problem.

Thank you, I need to figure out how you search for those issues, there are too many of them :) Yes, I think this PR solves this exact problem. There is a similar issue for popovers like a calendar as well.

[gziolo]

When I mouse-click outside of the modal dialog then More Menu remains opened. This is because Modal dialog prevents all events to be propagated below the overlay layer. We need to find a fix for it, @youknowriad any hints?

This is exactly how More Menu stays wrongly opened:

Once #17297 gets merged, this issues will automatically get resolved 🎉

[gziolo]

I rebased this branch with master and refactored some test utils and tests which use them to make everything work with the updated behavior of the dropdown menu and modal dialogs.

This PR is ready for the final review and testing.

[talldan]

Works really nicely in testing 🎉

[talldan]

It definitely feels like there needs to be a more general way to track that a modal or popover was opened from the context of another modal or popover, and exclude it from the focus outside check.

There's a similar issue here with the inline link popover, where it needs to check whether focus is in the autocomplete list to avoid closing:

gutenberg/packages/format-library/src/link/inline.js

Lines 168 to 179 in fb910e5

	onFocusOutside() {
	// The autocomplete suggestions list renders in a separate popover (in a portal),
	// so onFocusOutside fails to detect that a click on a suggestion occurred in the
	// LinkContainer. Detect clicks on autocomplete suggestions using a ref here, and
	// return to avoid the popover being closed.
	const autocompleteElement = this.autocompleteRef.current;
	if ( autocompleteElement && autocompleteElement.contains( document.activeElement ) ) {
	return;
	}
	this.resetState();
	}

Having said that, I can't think of a case where this logic fails, so I think it'd be pragmatic to ship this, and then consider what a more general solution might be.