Dialog

Title

• Be as concise as possible, yet clear and specific enough that users who read only the title might be able to confirm the action without reading the body. If the title gets too long, you can move the details to the body.
• Frame the title as a short statement that users need to confirm.
• Start with a verb, preferably the same verb the customer selected before the confirmation dialog appeared.
• Avoid phrases like "Are you sure...?" "Do you want to continue...?" or "Warning." These can imply a lack of trust in the customer's abilities.

Body

• Summarize the consequences of the action as concisely and as specifically as possible.
• Do not simply repeat the title.
• You can use passive voice if it makes the message clearer or more human sounding. Otherwise, use active voice.
• If data is inserted into the body text (especially at the beginning and end of a sentence) always use variables and punctuation. Consider how variables might affect translation. For example:
• Amount to be paid: {currencySymbol}{amount} 
• English -> Amount to be paid: £1,000 
• Spanish -> Amount to be paid: 1.000 € 

Button labels

• The call to action (CTA) is usually a button.
• Always include 2 options: one that allows customers to go forward with the action and one that allows them to change their mind.
• The verb in the button label should correspond to the verb in the title. For example:
• Title: 'Pay this invoice?'
• Button labels: Cancel Pay invoice
• Avoid using Yes, No, or OK for button labels, as they cause additional cognitive work. Make sure the button label expresses what will happen when users select it.

Localization

• Find the maximum number of characters that can be displayed and make sure the English label leaves enough space for longer languages.
• Communicate the restrictions to translators.

Requirements

Users should be able to:

• Open and close the dialog using assistive technology.
• Navigate to and interact with all interactive elements within the dialog.
• Scroll the dialog to access all dialog contents.

Interactions

Keyboard interactions

• Enter or Space. Triggers the dialog from a button.
• Focus should be pulled to the dialog itself.
• Tab. Moves focus to the first interactive element within the dialog: the close button.
• Pressing ‘tab’ within the modal moves focus between interactive elements.
• From the last interactive element within the dialog, focus should move back to the first interactive element within the dialog. Keyboard focus should cycle through the dialog.
• Escape. Closes the dialog.
• On dialog close, focus should be placed back on the element that triggered the modal.

Design considerations

• A dialog must be triggered by user action on a button.
• It must not be triggered by other elements or indirect user actions.
• A dialog should have a screen mask behind, to visually keep users focussed within the dialog.
• Do not overwhelm users by putting too much content in a single dialog.
• Either step the dialog or explore using a new page.
• Use a clear, descriptive heading, describing the modal's purpose.
• On smaller screen sizes, sticky headers and footers within dialogs must become unsticky and the entire dialog container must become scrollable. 
• Avoid overlaying dialogs on top of each other.

Development considerations

• The dialog should have role=”dialog” to allow screen reader users to identify the purpose of the dialog.
• The dialog should have a clear accessible name, provided by an aria-labelledby pointing at the unique id of the dialog heading.
• The dialog should have a h1 clearly describing the purpose of content within the dialog.
• The dialog should have aria-modal=”true” to trap screen reader and keyboard focus within the modal.
• Make sure that focus is returned to the trigger element when the dialog is closed.
• Make sure that the close button in the dialog has a clear accessible name, provided by an aria-label .