Non-modal dialogs

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.

The modal dialog can have different purposes: It may ask users to accept the use of cookies or to complete a survey, or it may offer additional information.

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.

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.

Cookie notifications

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.

Toast messages

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

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

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).

Stage 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.

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.

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.

General tips

• Name non-modal dialogs meaningfully. Refer to their visible heading via aria-labelledby, or provide an invisible name via aria-label.
• 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 role="dialog" and 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).

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)