A modal dialog is a window overlaid on the screen. Modals interrupt a user's task to either notify them of critical information or to force them to make or confirm a decision. The user must interact with the modal before returning to the main window. Modals are difficult to make accessible. Beware that open source resources that promote an accessible design may have accessibility issues. To avoid accessibility issues, use the CoTJS implementation.

The purpose of this page is to describe how to make modals accessible with an emphasis on issues to watch or test for.

Use Cases

Modals interrupt a user's task. For some users, interrupting a task can be difficult to recover from. Some users with attention issues may lose their focus on the task, some users with memory-related issues will experience disorientation, and some users may respond to the sudden, unexpected display of a modal with alarm.

Since they interrupt tasks, modals should only be used if it is essential to helping users complete their task. Examples of appropriate scenarios for modals are error prevention notifications (e.g., “are you sure…?”), and providing information critical to a process (e.g. form submission, saving information, etc.).

It is better to use modals in ways that are expected or predictable based on the typical flow of such tasks or by providing some warning to users.

It is not appropriate to use modals as the main window of an application. Modals have different experiences in different viewports and on different devices. Given they are so challenging to design in an accessible manner, using them as the primary interaction screen can block users from ever completing a task. Modals should only be used for dialogs.

Visual Design

To assist users to focus visually and conceptually on the modal, the non-focusable area behind it needs to be darkened to at least a 3:1 contrast ratio against the modal dialog.

The dialog itself should have a Close button.

Focus Management

Modals require careful focus management. Focus needs to move from the main content into the modal when opened and then released back to the main content when the modal is closed. In particular:

Modal Opened:

When some interactive element (e.g. a button) opens a modal, keyboard focus must land on the first interactive element in the modal. This is usually the modal’s Close button.

While Modal Open:

While the modal is open, users must only be able to access elements within the modal.

Keyboard users should not be able to TAB to elements behind the modal. Mobile users should not be able to swipe beneath the modal. Mouse users should not be able to click on elements outside the modal.

Note that in addition to managing blur and focus events to limit focus to the modal on desktop, mobile devices require the management of their “accessible focus”, which is designed to allow focus on any element on a page, including those which have a tabindex of -1.

In addition to managing the TAB key so that focus only moves among the focusable elements in the modal and never leaves the modal, pressing the ESC key should close an open modal.

Modal Closed:

When the user closes the modal (either with a confirmation button, cancel button, close button, or escape key), keyboard focus should return to the interactive element that opened the modal (if it still exists).

If the interactive element that triggered the modal no longer exists, focus should land at a logical and predictable place, preferably somewhere above the original trigger in the DOM. Note that, if programmatic focus lands on an element that no longer exists, visible focus will be lost and the user will disoriented.

Screen Reader Behaviour

When testing modals with a screen reader, specific behaviours are expected:

Modal Opened:

The modal should announce that it opened as well as announce its title.

While Modal Open:

When the modal is opened, the title and contents should be immediately read by screen readers.

While the modal is open, screen reader users must only be able to access elements within that modal. Screen reader users should never be able to “fall off” the modal such that they can read the content underneath it.

Modal Closed:

When the modal is closed, any success/fail status messages related to the modal should be announced.

In addition, the change of programmatic focus away from the modal will be announced by the screen reader. This should be the name of the interactive element that opened the modal (if it still exists). If the interactive element that opened the modal no longer exists, the new programmatic focus location is announced instead.

Resources

W3C WAI-ARIA Authoring Practices 1.1: 3.9 Dialog (Modal)

Modal Dialog Example - WAI-ARIA Authoring Practices 1.1

Browser not supported