[Accessibility] Overlay DOM position breaks screen reader focus order

[dgfranklin]

Bug

When an overlay is opened, it is inserted into the overlay container at the end of the document body. While one can control the tab-focus, particularly through the use of a focus-trap, it is difficult to control the screen-reader focus order. This came up in #7787, which was fixed (but only for dialogs), by making the rest of the page aria-hidden.

What is the expected behavior?

There should be at least two types of ways to handle focus on overlays, exemplified by certain Material components:

1. The "dialog" mode: A focus-trap is applied to the overlay, and the rest of the page is inaccessible while the overlay is displayed, with or without a screen reader.
2. The "menu" mode: An overlay is opened "in-line" on the page. The user should be able to move into and out of the overlay as if the DOM were next to the overlay origin.

What is the current behavior?

Mode 1 was fixed for dialog in #9016, but isn't easily accessible to custom overlays. I could copy the code over, but it would be nicer if the overlay service had a means to handle it.

Mode 2 does not exist. If you shift focus backwards in a screen reader when a component like MatMenu creates an overlay, it brings you to the bottom of the page instead of to the flyout origin.

What are the steps to reproduce?

Focusing on Mode 2 on the menu component, look at the provided MatMenu demo in StackBlitz:
https://stackblitz.com/angular/qyybdrnxmyx with a screen reader. (I've tested this on Chrome with VoiceOver on macOS so far, but I expect this effects most).

1. Click "Menu". The screen reader focus is moved to Item 1.
2. Navigate back (ctrl+option+left). This moves to the menu itself (no problem there).
3. Navigate back again. This moves focus to "Current build: ...." instead of the original Menu button. On a larger page, this problem will be made worse by all the other elements in between.

What is the use-case or motivation for changing an existing behavior?

Improved accessibility.

Is there anything else we should know?

This affects an internal Google product.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[ttma1046]

Hi, any updates?

[crisbeto]

We've landed this recently for autocomplete in #32282 and soon for select in #32363. We're also looking into doing it for menu.