Allow modal dialogs to trap focus, avoiding tabbing to the URL bar

[w3cbot]

This is a tracker issue. Only discuss things here if they are a11y group internal meta-discussions about the issue. Contribute to the actual discussion at the following link:

§ whatwg/html#8339

[niklasegger]

We discussed this briefly last year (see minutes) and I think Paul G.'s suggestion is the right way to go. Being able to tab from a modal to browser functionality is useful, for example to open a new tab and look something important up. Therefore, this should not be changed in the native dialog element. Also, that the communication is important, so that at respective places (official dev tutorials, etc. of W3C) it is explained that this behavior is normal and must not be "fixed" by own hand.

From a user perspective, there will probably always be two groups. Those who would like to keep the focus in the modal and those who do not.

I would of course be happy to hear other input.

Background info on the issue and on modals:

(I recommend reading the original discussion of the issue, because especially Scott O'hara gives really important input.)

The native HTML dialog element, or more precisely the modal variant of it, is used by more and more developers. However, it differs in its implementation from the previously common approach of the self-built modals and thus causes some confusion.

Tutorials and guides for such self-built modals, such as this one from the APG group, state that if you are on the last interactive element in the modal and press the Tab key, you jump to the first active element and vice versa and are thus "trapped" in the modal. Of course, they also specify that it should be possible to close the modal by pressing the ESC key, among other things.

(The focus of the tutorials on this APG site is the use of ARIA instead of native HTML elements. Nevertheless, older tutorials from other people/websites on the subject go in the same direction)

This differs from the native modal, where the content behind the modal is also hidden, but you can still tab into browser functionality, such as the URL bar.

Therefore, in the scope of this Github issue, the question came up which approach makes more sense (… and should be standard in the native modal.)

[matatk]

Discussed on APA WG call - @niklasegger to draft a comment from APA (posting here, or on-list), on which we'll run a call for consensus before posting in the WHATWG thread. Thanks @niklasegger!

[niklasegger]

Hello all,

(See my GitHub comment above for background info on the issue and the native dialog element. )

as discussed last week, I have now formulated the following response, which is welcome to be revised and eventually voted on in a CfC:

„We addressed this question in the course of several APA meetings and came to the conclusion that the current behavior of the native dialog element should be kept as it is. So, that you can tab from the dialog to the browser functionalities.

We see especially the benefit that keyboard users can, for example, open a new tab to look something important up or to change a browser setting this way. At the same time, the dialog element thus provides an additional natural escape mechanism (i.e. moving to the address bar) in, for example, kiosk situations where the user cannot use other standard keyboard shortcuts.

In addition, we also see how this can confuse some developers, as prior to the native dialog it was common when implementing a custom dialog component to really trap the focus. For this reason, we will also get in contact with the APG group to talk about a change in the guide for the dialog (modal) pattern. We think an additional note is useful, pointing out that when using the native dialog element, tabbing to browser functionality is normal and wanted, and does not need to be "fixed" by one's own hand. Since for many developers APG's guides are the go-to resource for implementing accessible components, hopefully this will prevent more confusion in the future.“

…thanks for reading! I think the last section should be revised to some degree. With "confused", a few people might understandably feel attacked. As a non-native speaker, I am missing the right word here, but maybe I'm also overthinking this.