Short description

Dialogues contain a headline, text and UI controls. They retain focus an required action has been taken. Use dialogues sparingly because they are interruptive to the user. 

When and how to use it

Use a dialogue when confirmation is needed. For example when deleting an account or removing a an item that is needed for something else not visible in this view.

They may also be used as a guide when an error has occurred that has a known way of handling the problem, for example when logging in.

If the need is to make a form or ask for more things, consider using centered modal instead

Behaviour

Can not be dismissed by clicking outside - the user is "forced" to take action. The content behind the overlay is locked and can not be scrolled.

The action of the primary button should confirm the user action that triggered the dialogue. For example, when a user is choosing an action that will delete an account and we want to verify that the user really want to do that, the primary button should be “Delete” (action), not “Cancel” (back away).

Placements

Modals on modals

When a slide-out triggers a dialogue, ensure that the dialogue is always centered on the screen. The overlay should cover everything behind the dialogue to create a clear separation between the foreground and the background.

Do this

Don't do this

Examples

Desktop

Mobile

The dialogue is often used to confirm an action that the user took, that could lead to a negative consequence, therefore:

• The title should be a statement referring to the action that will happen.
• The text in the dialogue should explain the action and its consequences.
• You may use an emphasized sentence in the message, but don't overuse it, and avoid please.
• The title of the dialogue should match the primary button. Avoid Yes, No, and Ok in the answer/buttons.
• The primary and secondary buttons must not be too similar. Don't make the user think about what button to click. Use Back instead of Close as the abort action if the primary action is Cancel.
• Also, put the action that the user made in the primary button. We might want the user to take another action, but that was the action they took. On purpose, or not.

Do's and don'ts

Do this

Don't do this

See examples and full accessibility guide on W3’s ARIA pattern guide for Modals

Tabbing order

Make sure the modal is announced, and that the focus and tabbing order is limited to the modal. The user should not be able to reach content outside of the modal without exiting the modal (same as for mouse-users). 

Heading structure

A modal’s main header always be a H2. While it is not wrong to make it a H1 since it is technically a new context, it is still experienced by the user as within the same context as the triggering page. Hence a H1 might be confusing. All following headers within the modal should descend below H2 as on a main page.

Navigation

Some modals include navigation. This could be pagination, Previous/next buttons for modals with several steps etc. Putting these in a <nav> element allows the user to find the navigation buttons more conveniently. If you cannot use <nav> in your context, aria role="navigation" can be used as a fallback.

Result from the latest accessibility review of the component (Angular+React): 2023-07-25

• Contrast: ok - but can be hard to see border
• Colour-blindness: good
• Code + aria: ok
• Touch + keyboard: good
• Dark-mode: n/a
• Focus: ok - need new style
• Reader: so-so - no close button name

• Details: Specification in Figma
• Instruction: How to access Figma