A non-modal dialog pops up on top of a page, sometimes triggered by the page and sometimes after some user action. The page below is still accessible, but is now often partly covered by the dialog.
A non-modal dialog in action
The following video shows a typical non-modal dialog that I triggered by the web page, not by the user.
A keyboard user looks at a page of the website of the city of Den Haag that explains how to order a passport .
- The page loads He starts tabbing through the page.
- There is good focus indication.
- A non-modal dialog pops up at the bottom of the page
- The user tabs on, focus is immediately on the elements of the dialog.
- The user dismisses the dialog.
Focus management problem: After dismissal, the focus jumps to the start of the page - not to the focus position before the dialog opened.
What qualifies as 'non-modal dialog'?
There are different definitions of what a non-modal dialog is. It is not always easy to draw the line.
For some, the main characteristics of a dialog, whether modal or not, is that keyboard focus circulates in it (that it "contains the tab ring"), which implies that authors must set focus to the dialog once it is opened.
Another view would hold that the main distinguishing feature of a non-modal dialog is that it pops up and covers up other content on the page without preventing access to the rest of the page. Tabbing beyond its boundaries or clicking outside might close this type of non-modal dialog.
A further aspect to consider is if the content that pops up is basically a form (in which case it is clearly a dialog), or more information-oriented, as in cookie notifications. In the latter case, a role
region is probably more appropriate than a role
dialog, but the boundary is not always clear-cut.
If the non-modal dialog is expected to remain available to the user, it would need a mechanism to move the focus to other parts of the page and back to the dialog. The ARIA Authoring Practices 1.0 (since deprecated) had suggested using F6 for that (see an error handling example from Deque), other approaches have been using CTRL + TAB.
Content triggered by the page after it loads (such as cookie notifications) or after some delay (such as popup surveys) are very common and can be a major nuisance for keyboard users. Some survey-type dialogs grab the focus, others don't. Most cookie notifications also don't, they avoid changing users' context unexpectedly. We cover them here under non-modal dialog, for want of a better place.
There is a variant of page-generated messages that disappears after a few seconds (so-called "toast" messages). Such toast messages may simpy say "Your enty has been saved" or "The form has been submitted". These are definitely not non-modal dialogs.
Toggletips or status messages appear on activation of buttons and also overlay page content, but they have no interactive elements that need to be focused. Therefore, they can be read via
aria-live once they are displayed. Compare the toggletip part of Heydon Pickering's Tooltips & Toggletips.
User-activated popups with interactive elements
Another type of content are popups that appear on activation of inline links, for example glossary popups that may contain a close button and a "read more" link, but close automatically when tabbing on or clicking outside of the popup. These are more complex than toggletips. They do not meet the criterion that they "contain the tab ring". We still cover them here under non-modal dialog.
Disclosure widgets also open when activating a trigger, which is typically a toggle button that will hide content when activated again. They do not "contain the tab ring". They reveal (and push down) content rather than cover it. The focus often remains on the trigger, which is OK if the discosed content follows directly after it (see the page on disclosure widgets).
Other user-activated widgets (sometimes called "stages") can cover most of the page, but typically do not trap the focus and do not auto-close when tabbing beyond their boundaries. They sit some way between disclosure widget and non-modal dialog.
Typical usability problems with non-modal dialogs
The following examples show the types of problems that users with different disabilities get when using non-modal dialogs.
1 Keyboard use: Dismissing the modal dialog
For keyboard users, it can be very annoying to locate and dismiss the non-modal dialog - especially when the focus order does not match the visual order.
A keyboard user opens the Website of the German Ministry of Traffic and Digital Infrastructure (bmvi.de).
- Immedialtely after accessing the start page, a cookie dialog pops up over the main navigation.
- The user repeatedly uses the TAB key to tab onwards in order to focus the OK button to dismiss the cookie info dialog.
- The user has to tab through the entire page until the OK -Button gets focused.
- The user hits ENTER to close the non-modal dialog.
It would be quicker to tab backwards to enter the end of the page and then tab upwards to reach the cookie info non-modal dialog, but this will not be obvious for most users.
Accessibility tips for non-modal dialogs
There are few hard-and-fast rules for non-modal dialogs. It really depends on context and content. Consider whether a modal dialog or a discosure widget might be a better fit.
Accessiblity tips differ for site-activated and user-activated non-modal dialogs.
- Name non-modal dialogs meaningfully. Refer to their visible heading via
aria-labelledby, or provide an invisible name via
- Label all dialog controls, including the close button. Each dialog should have a clearly labelled control for closing it. Icon-based buttons for closing [x] must have an accessible name that is read out to screen reader users.
- Use the correct ARIA roles. Use
aria-modal="false"on the dialog.
Site-activated non-modal dialogs
This covers non-modal dialogs that open automatically when the page loads (e.g., cookie notifications) or when the user has spent a short time on the page — typically, invitations to participate in a survey or to chat with staff, or promotional offers.
- Consider focus handling. Depending on the content and usage context, consider whether or not to set focus on the non-modal dialog when it opens. In most cases, non-modal dialogs that do not obstruct other content should not take away users' current focus.
- Make non-modal dialogs that cover content easily dismissable. If a non-modal dialog covers up page content, it is important that it can be focused and dismissed also via the keyboard. It is then best to set the focus to the dialog so keyboard users can easily dismiss it. (An exception are notifications in a stripe across the bottom of the page — here, users can scroll content into view).
- Ensure proper content order. If a non-modal dialog does not get focus and does not cover up other page content (such as top-of-the-page cookie notifications pushing down the content, or notifications at the bottom of the screen), place it in the content order where it appears visually, so users will find it when they want to close it.
- Consider announcing site-generated non-modal dialogs. Dialogs that automatically pop up after some time may be announced with
aria-live="polite"so screen-reader users are made aware of their appearance without the current focus being taken away.
User-activated non-modal dialogs
- In terms of content order, place non-modal dialogs straight after the element that triggered them. This way, non-visual users can arrow into the dialog content or tab on to its interactive controls.
- Alternatively, set focus to the dialog. If the dialog content cannot be placed right after the trigger, set the focus to the the first interactive element inside the dialog.
- Dismiss automatically when moving on. Close the non-modal dialog if a mouse click is registered outside the dialog's boundaries or the keyboard focus moves beyond its contents.
Note: When a non-modal dialog receives focus when opened, you may keep the focus cycling until the dialog is explicitly dismissed via a close button or by hitting ESC. So for keyboard and non-visual users, this type of non-modal dialog behaves more like a modal dialog. See the example from the City of Den Haag above, or the (somewhat dated) ARIA Non-Modal Dialog Example (Athena technologies, no date).
COMPARE cases with accessibility ratings
- Cookies, fixed position notification (bmvi.de)
- Survey popping up in non-modal dialog (taskrabbit.com)
- Non-modal-dialog for survey on a passport application page (denhaag.nl)
- Cookies, fixed position notification (comdirect.de)
- Nonmodal dialog, collapsible (comdirect.de)
Resources for non-modal dialogs
We have not yet identified comprehensive and current resources on accessibility best practices for non-modal dialogs. This is it so far:
- The current state of modal dialog accessibility (Scott o'Hara, Paciello Group, June 2018)
- Non-modal dialog for error handling (Deque University, no date)
- Outdated information on non-modal windows (W3C, WAI-ARIA Authoring practices 1.0)
- Keyboard method to jump out of NON-modal dialogs? (Github discussion on keyboard shortcuts for moving focus between different parts of the page without closing non-modal dialogs)