Keyboard method to jump out of NON-modal dialogs?

[patrickhlauke]

In https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal it says

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.

What are the means for moving keyboard focus outside the dialog window without closing the dialog? Is there a suggested key/key combination (which works reliably for web content)? CTRL+TAB? And if so, can that be expanded on and documented? Also, is it not acceptable to have non-modal dialogs NOT contain focus?

(and incidentally, the only other place "non-modal" is mentioned is in 3.23 Tooltip widget https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip "A hover that contains focusable elements can be made using a non-modal dialog." with no link or reference)

[patrickhlauke]

eagle-eyed colleague @IanPouncey just reminded me that the previous ARIA practices did have advice for non-modal dialogs https://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#dialog_nonmodal and that F6 (keycode: 117) was the suggested key there.

xref #102

[mcking65]

@patrickhlauke commented:

In https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal it says

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.

What are the means for moving keyboard focus outside the dialog window without closing the dialog?

1. Keep in mind that it is not always essential that you can move focus outside without closing the dialog. That will depend on the nature of the content and functionality. Example: a list of notifications and associated functions that overlay the page but do not render the lower layer inert. The ability to keep it open while working elsewhere may not be a valuable feature in all circumstances.
2. If moving focus outside the dialog without closing is valuable, there should be visible elements in the dialog that provide such functionality. For example, say a rich text editor shows a list of comments and revisions in a dialog. Activating a comment could move focus to the comment indicator in the document. Activating an element on a popup menu for the indicator could place the focus back in the dialog on the comment.
3. Hotkeys could also be defined. They may be associated with specific elements that are inside the dialog, on a toolbar outside the dialog, etc.

Is there a suggested key/key combination (which works reliably for web content)? CTRL+TAB? And if so, can that be expanded on and documented?

We will definitely document recommendations when we complete issue #59. F6 has been suggested in the past, It is intuitive on some platforms, but comes with implementation complexity given how the browsers use it. The same is true of ctrl+tab. This promises to be a thorny issue where we will have to thread a needle.

Also, is it not acceptable to have non-modal dialogs NOT contain focus?

If a container does not contain the tab ring, then it would be missing a key behavior of a dialog.
There are a wide variety of structural containers that could be used instead.
For example, a sidebar panel could be marked up as a region, even if that region is collapsable and moveable.
In that case, the disclosure pattern could be used.
The disclosure button could control a landmark region.
The region could contain an an actions menu that renders the functions for moving and sizing.

(and incidentally, the only other place "non-modal" is mentioned is in 3.23 Tooltip widget https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip "A hover that contains focusable elements can be made using a non-modal dialog." with no link or reference)

Right, I had to remove the reference because we didn't complete issue #59. And, we removed the previous content and raised issue #59 because we haven't yet worked on bringing that old content up to the editorial standards and getting consensus on what should be in the pattern.

[patrickhlauke]

Thanks for the response Matt. All good points that I look forward to seeing in the documentation :)

Regarding complexity of F6 (and CTRL + TAB) is the concern mainly about hijacking native browser functionality via preventDefault()ing?

[jnurthen]

related old issue https://www.w3.org/WAI/ARIA/track/issues/478/edit

[carmacleod]

@patrickhlauke

Regarding complexity of F6 (and CTRL + TAB) is the concern mainly about hijacking native browser functionality via preventDefault()ing?

Probably. :)
My 2c:

• I think hijacking CTRL + TAB from the browsers would be a problem and should be avoided.
• Regarding F6, however, I think of it as an "outer focus ring", separate from the TAB focus ring. It would be interesting to try handling F6 without preventing the default behavior. More thoughts on this below...

In old Windows desktop apps, F6 (SHIFT+F6) would navigate through "panels", including any open non-modals. Some apps still use it. You can see it in the Windows File Explorer (although behavior there now is not that different from TAB any more).

In Firefox (Windows and Mac) F6 navigates through the address bar, bookmark/history sidebar (if open), and document. (I believe it also [used to?] navigate through <frame> elements in the document, if any).

In Chrome (Windows only) F6 navigates through the address bar, bookmarks bar, document, and DevTools Console (if open).

I think of these areas as "landmark-like". I think it would be useful to have F6 (and SHIFT+F6) navigate through ARIA landmarks, non-modal dialogs, and the browser's address bar and other bars/sidebars, etc. (modal dialogs would be navigable also, but only between the modal and the browser areas).

If you use Slack, you can try out a nice implementation of landmark navigation using F6 (SHIFT+F6) in their desktop app. (They don't appear to have any non-modal dialogs, but if they did, I wouldn't consider it a stretch to add them to the "F6/outer focus ring" navigation).

When inside a web browser, Slack uses CTRL+F6 (CTRL+SHIFT+F6) for landmark navigation. Presumably they didn't want to hijack the browser's F6 (SHIFT+F6), or perhaps they tried merging their navigation with the browser's and decided that it was too problematic - I don't know. (I'm wondering if the user needs to type an extra F6 to keep moving forward after the browser focuses the document).

Sure would be nice if the browsers would implement this, instead of everybody having to roll their own.

[jnrepo]

Is there a need to implement a global keyboard shortcut on mobile phones as well? I can't seem to find anything about that in the w3 docs.

[patrickhlauke]

people use physical keyboards and keyboard-like inputs on "mobile" (i.e. on touchscreen devices) as well. related: https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

also, if the "mobile" view is triggered just by media queries/viewport dimensions, even users on non-touch devices will see it if they zoom or resize their browser.

in short: yes.

[jnrepo]

Is there a recommended key that can be used for both mobile and desktop? I'm not sure how f6 or ctrl + f6 would work for both.

[patrickhlauke]

to be clear, talking about actual physical keyboards (bluetooth keyboards for smartphone/tablet) which do have function keys, Ctrl, etc. not the on-screen keyboard on the touchscreen, which yes lacks those.

for example, this (from my article above)

[DanHolbrookQA]

There are a lot of open issues around non-modal dialogs, but I guess I'll throw in my lot here because it's specific to keyboard methods: I think it's worth discussing tab/shift-tab as an option. My basic arguments are:

1. The HTML5 dialog element allows it
2. In practice, it's how many/most non-modal dialogs (or things-that-look-identical-to-dialogs-but-we're-choosing-to-call-something-else-for-reasons-of-philosophical-purity) work on the web today.
3. It's more intuitive than an alternate control, especially when there are other elements that would not use that control but would look similar and support tabbing out.

The specialists at my org discussed this internally and read up on the recent articles as well as these threads, and ultimately our consensus was that it seemed like there were enough other semantically important associations with "dialog" (this element is not the main content, this element is covering part of the page) to warrant having something called a dialog that you can still tab or shift tab out of when it's non-modal.

And for our users (and I think this is generalizable, at least on the web) we think that allowing the standard, most common keyboard navigation method is more intuitive than F6 or other options.

We've loosened our definition from matching the implicit W3C one and have instead gone with "Non-Modal Dialogs are content that requires user input and are overlayed upon the page, but unlike modal dialogs, keyboard and mouse users can interact with content outside of the dialog." - with no inherent restriction of tab/shift-tab.

[patrickhlauke]

@DanHolbrookQA the wrinkle there from a user's point of view being that for non-modal dialogs, users generally may want a quick way to switch in and out of the dialog ... if that isn't handled, and it just relies on "users can tab through the page until they encounter the dialog", that then defeats the purpose of non-modal dialogs that non-keyboard users have - the easy availability of things in parallel with the main page. also, as this will then depend on where in the markup the non-modal dialog actually "lives" I assume - and in dynamic implementations, that usually at the end of the page. so a user may well be able to tab out of the non-modal dialog, but now they're right at the end of the page, and likely not where they originally were in the page when they first triggered it.

in short, it feels a bit lacklustre... /cc @scottaohara

[DanHolbrookQA]

Oh, yeah probably not the "best" method in all cases, but I think there are cases where it will be worthwhile as an option (e.g. an AI chat non-modal dialog that's last in the page order anyways - you tab out, you wrap around, you're back to the top of the page where you wanted to go) and it's worth allowing. I'm also willing to sacrifice elegance for intuitiveness here. Everyone would have to learn any new shortcut, but everyone knows tab.

[electrickite]

@patrickhlauke As you say, that would depend on the implementation. A date picker non-modal dialog, for example, placed inline in the DOM in a reasonable location, might make a lot of sense as a candidate for the "just allow the user to tab out" approach. It's also telling (or at least consistent) that the the native dialog element does not seem to constrain focus in the standard "non-modal" mode, but does constrain focus when opened in modal mode with showModal().

[scottaohara]

HTML's dialog presently allows tab to move out of a non-modal dialog... but there are also issues open to discuss whether that should change... mind you, it might not be possible at this point, or desirable in general for a native HTML element which could be plopped onto a page and then used nefariously to trap a user's focus. I think it's a mistake to look at the native HTML non-modal dialog and determine that it's making a statement on its usability, when the reality is that there is currently no consensus on non-modal dialog behavior, and doing anything without consensus could be problematic.

Re: there are instances of content that are non-modal dialogs but they allow tab to leave them. Well, are those proper dialogs then? Or, are they invoked from an element that provides an expectation that one might be able to tab out of them (but tabbing woudl return to the invoking element and not send you to some random location in the DOM?) Are they some other type of popup/popover where it is expected for keyboard focus to leave it? I'm not necessarily saying there aren't instances where a non-modal dialog could allow tab key to exit it - but I also question if that's the 'default' right choice.

FWIW, for many Microsoft products, Ctrl + F6 if a very commonly used command to move from/to containers that soft-trap keyboard focus (e.g., non-modal dialogs). This again is part of one of the HTML issues concerning non-modal dialog keyboard accessibility - a potential to standardize this behavior.

[scottaohara]

but does constrain focus when opened in modal mode with showModal().

it doesn't constrain focus though. it makes the web page inert so you can't access the content outside of the modal dialog. But, focus can freely move in/out of the dialog to the browser chrome (it's ui)

again - HTML imo is doing a good thing here and not trapping a user into a potentially harmful web page (by fully constraining keyboard focus to the modal - or in the case fo this larger thread - non-modal dialog) / accounting for the fact that any shmo might slap a dialog onto their page without an interactive element to close it.

[electrickite]

it doesn't constrain focus though. it makes the web page inert so you can't access the content outside of the modal dialog. But, focus can freely move in/out of the dialog to the browser chrome (it's ui)

@scottaohara True, I'll concede that point, but that is also the case even for the browsers' own dialogs outside of web content. For example, triggering a browser alert dialog with alert('hello'); brings up a dialog that prevents the user from interacting with web content, but still allows the user to Tab out to the browser chrome.

But, as you say, we probably shouldn't rely on exactly how browsers are currently handling these elements when thinking about how to standardize. I'm just pointing out that the behavior @DanHolbrookQA mentioned certainly exists in the wild and may have valid use cases, so prohibiting that behavior could have unintended consequences.

Re: there are instances of content that are non-modal dialogs but they allow tab to leave them. Well, are those proper dialogs then?

I think that's one of the core questions here - there is currently a lot of uncertainty in the community about what precisely it means for a dialog to be "non-modal", when the dialog role is appropriate, etc.

[pauljadam]

Dialogs should have a TAB ring regardless of modality. A TAB ring does not actually trap a keyboard user's focus in the dialog, they can use F6 or Command + L to move focus to the browser toolbar buttons.

[DanHolbrookQA]

Re: there are instances of content that are non-modal dialogs but they allow tab to leave them. Well, are those proper dialogs then? Or, are they invoked from an element that provides an expectation that one might be able to tab out of them (but tabbing woudl return to the invoking element and not send you to some random location in the DOM?) Are they some other type of popup/popover where it is expected for keyboard focus to leave it? I'm not necessarily saying there aren't instances where a non-modal dialog could allow tab key to exit it - but I also question if that's the 'default' right choice

This is why I was lumping together the non-dialog modals and their look-y likes. If those other elements allow tabbing out, is my non-screen reader experience to try the shortcut to see if it works (assuming I know it), realize this is a False Dialog when it doesn't, and then tab as usual? If the dialog element currently does not constrain focus, and many things that most people are at least conceptualizing as dialogs in coding and design do not currently constrain focus, then I'd argue that a non-modal dialog should continue not to do so, and additional shortcuts are icing on the cake.

There are some potential concerns around non-modals with Focus Not Obscured, but they exist no matter the exit method, and on the screen reader side the dialog attribute has good (if imperfect) support for announcing dialog boundaries, so it seems like a greater convenience to allow this tab-out method than to lock it down as an inherent aspect of anything-dialog.

[patrickhlauke]

I just realised yesterday was this issue's 6 year (!) anniversary. Still have high hopes something could be done/documented officially here, with a nice working example...