WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard trap for non-modal dialogs and popups:

for

From: Lovely, Brian (CONT)
Date: Sep 22, 2016 6:55AM

JP, I support the trapping in a modal to an extent, as it seems to provide an experience analogous to that of a sighted user. For a sighted user, using the mouse, a modal opens over a semi-opaque overlay that blocks all interaction with the rest of the page until the user dismisses the modal via either the close button or possibly also the escape key. For a non-sighted user, the technique to emulate this is to put all page content in a container, and the modal outside that container. When the modal is opened, that content container is set to aria-hidden="true" to emulate the semi-opaque overlay, and tab and/or arrow keys cycle through the modal contents, hence the "trapping" of focus within the modal. I would think this would be better than being able to move off the end of the modal and possibly having trouble getting back to it, or being unable to quite decide where the modal contents end and page content begins.

The flow would be as follows:

A button or link is encountered that will trigger the modal. It's text and surrounding context communicate that it is for completing some specific task.

The modal opens, and focus is shifted to the modal wrapper. A reference to the triggering element is stored so it can be returned to when the modal is dismissed.

Focus is trapped in the modal.

The user performs the task at hand, or decides not to do so at this time.

The user presses tab or an arrow key to cycle back to the close button and dismisses the modal.

The aria-hidden attribute on the page content is set to "false" and focus is returned to the link or button that originally triggered the modal