Should a focus trap prevent a user from reaching the context UI like e.g. the browser?

Question

When we trap the focus inside a modal, should the focus cycle within the modal or should a user be able to reach the outside, like let's say the browser UI?

It's not clear from the official specifications for the web: https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

At least in an example provided by said specifications, it's actually like so, that you are not able to reach anything but focusable elements in the modal: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html

This comes with side-effects like breaking the developer tools: Here's a video for further clarification: https://streamable.com/i4zcsp

Answer 1

Excellent question! My short answer is: It should not allow to tab outside the modal.

Long answer:

Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.

This leads to two things:

1. Tab and Shift + Tab are trapped. Reaching the last (first) element will move the focus to the other end.
2. You have „means for moving keyboard focus outside the dialog”. But then, you must close the dialog.

So when you register a key event listener (and handle Esc to close the dialog and restore focus), you should also handle the mentioned Ctrl+L for reaching the URL bar (resp. Awesome Bar) and perhaps Ctrl+K for the search bar.

Find more keyboard shortcuts for

• Firefox
• Chrome
• Chromium
• Edge
• Opera
• Safari

Given the variety, you might want to dismiss the modal on everything that was not handled inside. User tests would give you a hint on what people expect.

Regarding the developer tools: Opening them in another window might do the trick.