-
Notifications
You must be signed in to change notification settings - Fork 6.8k
Description
Bug, feature request, or proposal:
If a sidenav is open and in the 'side' mode, then focus should not be trapped within the element. Users with screen readers should be able to flow from that content to the main body of the page. I noticed that within drawer.ts, even when _isFocusTrapEnabled is false within drawer.ts, the focus trap is still being constructed in the ngAfterContentInit lifecycle hook. This constructor has side effects of making the content of the drawer trap focus.
I propose that this focus trap should only be constructed when isFocusTrapEnabled is true. Alternatively, an input on the element to control this behavior would also be sufficient.
[1] https://github.com/angular/material2/blob/master/src/lib/sidenav/drawer.ts
What is the expected behavior?
For an open sidenav in 'side' mode, focus should not be trapped. Only dialogs and menus should trap focus.
What is the current behavior?
The sidenav is trapping focus.
What are the steps to reproduce?
Demo: https://stackblitz.com/edit/angular-psfyn2
I'm using the NVDA screen reader in browse mode on Chrome.
- Click within the sidenav to bring focus to the demo
- Use the up and down arrows, notice that it loops around from the bottom element to the top if you use the down arrow
What is the use-case or motivation for changing an existing behavior?
I've been working with an accessibility tester who let me know that it is very confusing for focus to be trapped in this element since it is not a menu element. This can cause screen reader users to get trapped within a menu with no clear way to get out.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Using Angular2 and the latest Material. I am reproducing the issue on Windows & Chrome with the NVDA screenreader.