[Accessibility] Overlay DOM position breaks screen reader focus order #10302
Labels
area: cdk/a11y
area: cdk/overlay
feature
This issue represents a new feature or feature request rather than a bug or bug fix
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
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:
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).
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.
The text was updated successfully, but these errors were encountered: