Dialog

Introduction

In traditional desktop operating systems, a dialog is a child-window that typically will either communicate information to the user, display a prompt for input, or allow the user to verify or cancel an action.

Whilst these cases are also valid and true on the web, we also see much more generic use of the dialog (for better or worse). For example, a dialog itself might contain an entire full page-like experience, navigation or settings.

This "generic" dialog is discussed here, and falls under the umbrella of progressive disclosure, but also familiarise yourself with the following, more specific dialog patterns:

TIP: On large screens, dialogs are typically "light-boxed" in the center or "panelled" on one edge, with a mask covering the remaining portion of the screen. On small screens however, the dialog may cover the entire screen.

Working Examples

You can take a look at the generic dialog pattern in action on our examples site.

You can get an idea of the required markup structure by viewing our bones site.

Terminology

dialog

the pattern as a whole, containing button, overlay and mask

button

the button that opens the overlay

overlay/window

contains the actual content

title

the title of the dialog

mask

an element that visibly masks the content "behind" the window

We use the terms "overlay" and "window" interchangeably. They mean the same thing.

Best Practices

A dialog is typically opened in one of two ways:

Click-activated: explicitly opened and closed by clicking the button

System-activated: automatically opened by the system/application on page load or at some other arbitrary time

Opening dialogs that are not requested by user (i.e. system-activated) are a violation of WCAG Guideline 3.2.5 (Level AAA) and therefore should be reserved for exceptional circumstances only (i.e. not ads!).

Overlay must not be opened on hover or focus of button (or any other element).

Overlay must be opened on click-event of button or via an application event.

Overlay must use ARIA role of dialog (not alertdialog in this context).

Overlay must contain a button that can dismiss the dialog (this will be 'close', 'cancel' or 'okay', depending on the specific type of dialog).

Overlay must contain at least one interactive element (this can be the close button).

Overlay must be labelled by an onscreen element (a heading for example) or explicit attribute.

Overlay must start heading hierarchy at level 2.

Mask must be positioned between page and overlay.

If the overlay contains critical content, the content must be available without JavaScript. For example, the content could exist either at an alternative URL or elsewhere on the same page.

Window

To assist older screen reader versions (NVDA in particular), any immediate child of the dialog role must have a document role (if it contains content). In time, as screen reader support improves, the requirement for this role may go away.

Mask

If the window does not cover the full screen, which is usually the case on desktop, a mask will be needed to prevent clicks on the page content behind the window.

A more specific type of dialog may feature a different, and more prominent, way to dismiss a dialog. For example, an 'Okay' button in an alert dialog, or a 'Cancel' button in a confirmation dialog. In such cases the close button can be omitted from the header.

Presentation (CSS)

Once we have our markup in place, there are many different ways to visually, and uniquely, style a dialog.

The most important aspects for accessibility, are the mask and the hidden state.

Hidden Polyfill

First of all, let's provide a "polyfill" for older browsers that do not support the hidden attribute.

[hidden] {
display: none;
}

Mask

The mask creates a visual distinction between the overlay content in the foreground, and the page content in the background.

It must also prevent pointing devices from interacting with the page content behind the window.