Modal dialog: consider allowing Tab/Shift+Tab to escape to browser chrome

[nolanlawson]

Under keyboard interaction for a modal dialog, it says the behavior for Tab should be:

If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.

For Shift+Tab, it recommends the reverse:

If focus is on the first tabbable element inside the dialog, moves focus to the last tabbable element inside the dialog.

The native <dialog> element disagrees with the spec in this behavior. Instead of cycling through elements inside the modal dialog, Tab and Shift+Tab cause focus to eventually escape to the browser chrome itself (URL bar, etc.). In other words, when you reach the end of the list of tabbable elements, the "next" or "previous" tabbable element is inside the browser chrome, not at the opposite end of the modal dialog. This occurs in both Chrome 87 and Firefox 85 (with the flag dom.dialog_element.enabled).

The <dialog> spec only says that, when showModal() is called on the dialog, every other node in the document should become inert. So when focus escapes to the browser chrome, it's effectively just a product of the fact that this is how a normal web page works even without a dialog. On example.com you can press Tab and Shift+Tab to eventually arrive at the browser chrome.

Because of this, it seems reasonable to me to modify the WAI-ARIA Authoring Practices to allow for Tab and Shift+Tab to escape to the browser chrome. I would propose making it optional – focus can either cycle through the tabbable elements inside the modal dialog, or it can eventually escape to the browser chrome. (In either case, tabbable elements in the document but outside the modal dialog would not be reachable.)

There is actually a precedent here with window.alert and window.prompt. As I understand it, these used to be browser-modal (i.e. would block the entire browser), but are now content-modal (only blocking the relevant browser tab) in modern version of Chrome, Firefox, and Safari. (See relevant Firefox bugs.) This means that you can Tab through the focusable elements inside the modal, and eventually wind up in the browser chrome. So arguably, the WAI-ARIA guidelines for a modal dialog should be the same.

It's also worth mentioning that using the native <dialog> is apparently the only way to allow for keyboard interaction with closed shadow roots and user agent shadow roots (such as <video controls> and <audio controls>) when inside a modal dialog. And this behavior cannot be combined with the "cycling" Tab behavior – it's not possible for web authors to control focus change inside of closed/UA shadow roots. So if <dialog> is considered inaccessible per WAI-ARIA, that would leave web authors with no good options. (I'm disregarding other accessibility problems with <dialog>, which at least seem solvable on the part of web authors or screen reader vendors.)

[mcking65]

I'd like to propose the inverse; the behavior of the HTML <dialog> be revisited.

One lens to consider is how web pages are increasingly serving the purpose of apps and browsers are in that case analogous to operating system environments. In native OS dialogs, tabbing through a dialog does not allow focus to move into the operating system chrome, e.g., the Mac Dock or Windows task bar and start menu. In native OS apps, there are special keys, like cmd+tab and alt+tab and the Windows key for moving focus outside the app to other apps and the operating system itself. Similarly, browsers have dedicated keys for moving to other tabs, to the menubar, and to the address bar. In fact, I'd argue that even without a modal open, it would be better if tabbing from the last element on a web page were to wrap to the first element, at least by default. I'd similarly argue that browsers should do a much better job of helping keyboard users learn how to navigate efficiently.

Perhaps more important, though, is to consider why native OS modals behave the way they do. A primary benefit of modals is to keep focus on a task. Allowing focus to jump outside can not only negatively impact efficiency by adding many elementts to the tab ring (easily a couple dozen or more in some browsers) but enables users to get lost and unsure of how to return to the task. This problem is exacerbated by the geographic distance between the browser chrome and many modals. In other words, enabling users to tab outside a modal defeats the purpose of the modal.

Note that this is my own view; I'm not speaking for the APG task force. I'd like to get more input.

[sinabahram]

HTML is wrong on this point. It's really that simple. Modal dialogs should be modal. screen reader users, and keyboard-only users at large, have enough to deal with. I very much hope and trust that we will not take steps to align against HTML on this incorrect and harmful behavior to users with disabilities. Dialogs should be modal. That has worked well across platforms from televisions to the web to desktop applications to mobile phone apps to my toaster oven.

+1 to every single thing that @mcking65 said above.

[MarcoZehe]

I would like to add my support to what Sina and Matt said. I also think, that browsers should adapt and the dialog element should be truly modal.

[jscholes]

There isn't much I can add to what @mcking65, @sinabahram and @MarcoZehe have already said, in terms of expressing my opinion. I do want to raise one point though:

@nolanlawson

There is actually a precedent here with window.alert and window.prompt. As I understand it, these used to be browser-modal (i.e. would block the entire browser), but are now content-modal (only blocking the relevant browser tab) in modern version of Chrome, Firefox, and Safari.

I've put together a test page which allows you to open several types of built-in modals:

https://jscholes.github.io/modal-alerts.html

The first three use window.alert, window.prompt and window.confirm, respectively. The last three are related to file/directory pickers, so are platform-specific. But they don't allow access to the browser chrome, and therefore may contribute to user expectations of how modal dialogs work in a browser.

I haven't had a chance to test in macOS Safari. But in Google Chrome Canary, I can't reach the browser chrome after invoking any of the six examples. In Firefox 85, I can reach the browser chrome from the first three; the second three don't seem to work at this time.

[jscholes]

Additional note of unexpected behaviour: on the sample page, activate the "Ask for confirmation" button to invoke a window.confirm-based modal. In both Firefox and Chrome on Windows, you can use Right/Left and Up/Down Arrow to move through the two buttons, which is standard dialog behaviour.

In Firefox, pressing Down Arrow or Right Arrow while the "Cancel" button has focus ends up moving into the list of open tabs. From that point, you can't press Left or Up Arrow to reverse your action, because both will result in the tab being changed. Or nothing, if you only have one tab open. Both possibilities are pretty rubbish.

The same also applies in reverse. If you have the "OK" button focused and hit Left/Up Arrow, you end up in whatever is the last focusable area before the page in the browser's chrome, e.g. your history sidebar or a toolbar with add-on-related buttons. Again, you can't reverse your action by using the opposite keypress.

I don't think most people will implement this custom arrow key behaviour when making a custom modal. But arguably, the browser should when displaying a <dialog>. Tab/Shift+Tab is one thing, but having the arrow keys move out of the page entirely is bewildering.

[MarcoZehe]

CC @jcsteh for awareness re the Firefox arrow key behavior from the previous comment.

[accdc]

Personally, I support keeping the browser chrome out of the tab order when dealing with ARIA modal dialogs. There is no accessibility benefit by ensuring that this is preserved, it is confusing for non-sighted screen reader users who find themselves within then suddenly outside of a modal dialog, and there are already browser keystrokes designed for moving focus to the browser chrome anyway which will continue to work from within an ARIA dialog. E.G F6 and Alt+D, so there is nothing that is being made less accessible by ensuring tab focus remains within the dialog.

[nolanlawson]

Thank you everyone for the feedback! And thanks @jscholes for the demo page. I can confirm in Chrome on both Linux and macOS (with "use keyboard navigation to move focus between controls" enabled) that it matches the behavior you describe. I must have tested Chrome incorrectly.

I also tested Safari on macOS, and it appears to follow Firefox's behavior: focus escapes to the browser chrome for all three of window.alert, window.prompt, and window.confirm when pressing Tab. But as others have said, this isn't necessarily the ideal behavior – perhaps Chrome is the only one doing this correctly.

If the consensus is that WAI-ARIA is correct and <dialog> is wrong, then it seems to me there are two possible solutions on the <dialog> side of things:

1. Define Tabing behavior in such a way that focus cycles through the DOM rather than escaping to the browser chrome, even on pages without a <dialog> (as argued by @mcking65). This would "automatically" fix the modal <dialog>, since it is just defined as an element where every other element on the page is inert.
2. Define Tabing behavior in such a way that focus cycles through the DOM, but only for a modal <dialog>. For instance, define the concept of a "focus trap" and apply it to the modal <dialog>.

I couldn't find any existing issue on the HTML spec (although whatwg/html#2171 is close). Should we open an issue and move discussion over there?

[sinabahram]

+1,000 to option 1, but option 2 is a fine fallback in case that does not gain support.

[smhigley]

Restricting tab from entering the browser chrome makes sense to me, though I have some qualms specifically about using aria-practices to put that responsibility on authors.

The reason is that we'd create an issue where aria-practices implies that using the inert attribute doesn't fulfill the stated keyboard interaction model. While having authors correct for the current browser experience sounds nice in theory, the problem I run into in practice is the way individual devs and component libraries actually implement focus traps ends up being much buggier than just using inert and letting the browser handle it.

Could we have some wording along the lines of "Tab does not move focus into the inactive parts of the page while the modal is open", then follow up with browsers and the HTML spec?

[MarcoZehe]

I must admit I am a bit torn about this one. I think the focus trap should have been included in the spec for inert and dialog in the first place, when the ARIA Authoring Practices/Design Pattern had already agreed on the focus trap. Also, the focus trap existed when browsers were still doing per-window alerts and other dialogs, and only started "softening" when they went to per-tab "modal" alerts etc. I put modal in quotes on purpose here, since they aren't really modal in the classic desktop dialog sense, but for the best user experience, they should be.

So while I agree that there are developer implementation burdens right now, the ARIA version of "modal" gives the much much better user experience for keyboard and screen reader users than the current browser implementations of "modal". Losing context by going into the browser chrome from a web dialog is just a cognitive burden that needs to go away ASAP.

I advocate for strongly urging the spec and browser vendors to implement inert and dialog properly to be truly modal to the tab, without going into the browser chrome with the tab key when such a dialog is open. It is modal for a good reason and needs to be absolutely confined.

My 2 Cents.

[sinabahram]

Given that there seems to be rather strong consensus around option 1 as stated above e.g. defining tab behavior not to escape to the chrome of the browser, how can we move forward to make sure there is alignment both within ARIA for the time being and then HTML eventually, so that there's no gaps in this definition?

[carmacleod]

@mcking65
You asked about the spec for tabindex: https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex