Use a modal when a user must complete an additional task within the context of another in-process task and there isn’t a good way to present the new task within the existing page. For example, an application might use a modal to prompt the user to verify their shipping address after a user submits their address information but before they continue to the next step of the checkout process.

If a modal is the entry point into a new process that does not rely on context from another task, using a new page instead of a modal may be a more usable and accessible approach.

Generally, it’s best to avoid putting forms in models. In some circumstances, it’s OK to have 1 or two fields for simple operations, but most of the time it will be better to place those form elements on a new page.

Opening the Modal

When a modal opens, the focus should generally be set to an element at the top of the dialog. Avoid focusing the entire dialog if it is large as large focus regions make it hard to identify the point of focus and can complicate navigation for some users.

Closing the Modal

The modal should contain a visible button element that will close the dialog. This button must be in the tab sequence when the modal is open.

When the modal closes, the element on the page that resulted in the modal opening should be focused.

Keyboard Trapping

Modals are one of the few times where a keyboard trap is the desirable behavior. Tabbing through a modal will wrap around and return to the top of the modal as long as the modal is active.

Modals are typically presented visually on top of a dimmed out page to indicate that the page can not be interacted with while the modal is open. It’s crucial that what content can be interacted with with the keyboard and what appears to be interactive visually are consistent.

Avoid creating workflows where more than one modal will be open at the same time.

Important Markup

role=dialog All elements that control the dialog (such as buttons) must be within this container.

aria-modal=true This should be set when the modal is opened. It tells user agents to ignore content outside this container.

The dialog must have a visible title that is referenced by aria-labelledby or have a value for aria-label.

QA example script

The following checklist can be used during development or QA to ensure that a dialog satisfies the baseline accessibility requirements.

The modal dialog box must:

• receive focus on open
• inform the user that it is a dialog
• provide a heading that says what the dialog is about
• prevent mouse clicks outside the dialog while open
• prevent scrolling the page while the dialog is open
• prevent tabbing to outside the dialog while open
• can be operable with a keyboard (allows the ESC key to close the dialogue)
• return focus to last focused element on close

Projects at Truss that have used accessible modals

• EASi
• MC-Review

Further Reading

WAI-ARIA Authoring Practices 1.1: Dialog (Modal)

Alert

An alert is a simplified type of Modal that a user can only interact with by confirming or closing. In most cases, it’s better to handle notifying users using less intrusive means.

For alerts that ask for a user to confirm that an irreversible action should be completed, focus the button to decline the action to prevent accidental acceptance. For less critical situations, it’s OK to focus the accept button to make it quicker for the user to proceed.

Further Reading

WAI-ARIA Authoring Practices 1.1: Alert