Controls below the angular material dialog overlay still can be focused by keyboard

[new-mikha]

Bug, feature request, or proposal:

Bug

What is the expected behavior?

The dialog should be completely modal.

What is the current behavior?

Controls that are below in z-order of the Angular Material dialog overlay still can be focused by keyboard.

What are the steps to reproduce?

• Go to the stock Angular Material Dialog example: https://material.angular.io/components/dialog/examples
• Close the Dev Tools if it been opened earlier (this will just allow less TABs to press later, see below)
• Click on the Pick One button, the dialog pops up
• Click the browser address tab (Chrome on Windows been used for test)
• Start pressing TAB on the keyboard - you will notice that controls underneath the dialog overlay are getting selected, with all keyboard interaction enabled for the selected control. E.g. it's possible to enter new values into text boxes, press buttons etc.

Out of curiosity I also checked Bootstrap Modal - it also got similar problem, but for that one Shift-TAB needs to be pressed to reproduce.

As a suggestion - I understand that the dialog overlay is currently based on cdkTrapFocus directive. This one is suffering from the same problem, I presume it's exactly same problem, so it would be nice to fix it on the level of cdkTrapFocus - because the focus trap is quite useful thing.

[jelbourn]

The solution on this one is to change the way we do focus trapping. Instead of catching focus and redirecting, it needs to effectively disable everything on the page. This is something already on our backlog.

[swinkel17]

@jelbourn do you guys have any idea when this bug may be fixed? I'm using it for a project that needs to go live in a couple months and this is an accessibility concern

[jpzwarte]

I cannot seem to reproduce this issue with MatDialog. I can however reproduce it with CdkDialog. The main difference afaics is the moment when the focusTrap is created. For CdkDialog, this is during class instantiation. For MatDialog, this is delayed until the enter animation is done. Perhaps this has something to do with the bug in CdkDialog? cc @crisbeto

[calebegg]

I can still reproduce this, just following the steps in the original report.

I don't think you need to disable everything on the page; https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html doesn't do that, and is still effective at trapping focus. The trick seems to be catching the 'focus' event on document

[jelbourn]

@calebegg Yeah, that would be a good improvement to the existing implementation for now.

@crisbeto what do you think? It should be pretty straightforward to add a focus listener to body while a focus trap is active and redirect back into the region

[crisbeto]

@jelbourn How would we handle the case when there are multiple focus traps on the same page which would be competing for the focus?

[jelbourn]

We'd probably want to do the most recently focused one.