Modern Enterprise UI design — Part 2: Modal dialogs

Design, best practices and accessibility

In my previous post, I highlighted the challenges of designing for enterprise and tackled one of the most commonly used User Interface (UI) components, tables (if you haven’t read it, please check it out).

This time we’ll take a look at another common UI component found in enterprise software — modals.

Note: I’m going to assume we’re working on a web-based application although the majority of the points below apply to any enterprise application regardless of platform.

Firstly, what are modals?

Modal windows, also known as dialogs or overlays, are UI components that sit on top of the current page, usually with a semi-transparent layer behind them to separate them from the main page. They disable interaction with the rest of the page and force the user to first interact with the modal window. Modals are great for allowing a user to stay in the context of the current UI while being able to perform related actions without interrupting the workflow on the main page.

When to consider using a modal

Modals are useful in many situations, where sending the user to another page might be disruptive. They should almost exclusively be triggered by user interaction. The purpose of the modal should be immediately apparent to the user.

Gathering input from the user

Using a modal to add records to a table

Allowing a user to add items to a displayed list or table without a page redirect is a common pattern for a modal window. This is especially useful when the user might be repeating the action over and over.

Displaying additional information

Quickly view additional information

When displaying a table of records, it may not be possible to display all of the related data for each row. Using a modal to display additional information about a row quickly allows the user to stay in context and avoids redirecting them to another page.

Displaying critical information

Displaying critical information, such as a session timeout warning

Events that block a user or need immediate action from the user such as a session timeout warning/expiry notice.

Confirmation of destructive actions

Confirming destructive actions

Warning a user that deleting data may have a broader impact or that the action is irreversible.

Splitting up complex tasks into smaller steps

Multi-stage modals

Some tasks may involve various steps of actions. For example, importing data and then configuring options based on the imported data.

Feature announcements

Announcing a new feature

These should only be used rarely for critical announcements. Often some other form of in UI notification is preferred as informing users this way can quickly become spammy. If used, consideration should be given to when the modal is shown, and also that users’ tasks aren’t interrupted. Also, ensure users have a way of finding the announcement again if dismissed.

When not to use a modal

As modal windows block the user from interacting with the rest of the page, they should only be used when redirecting the user would break the flow of the interaction or task at hand. Misused, they can very quickly become annoying to the user to the point where they form a habit of dismissing them on instinct.

❌ When the user hasn’t triggered the modal

Randomly showing a modal is a jarring experience and confusing for the user. The only exception to this would be a time-critical notification, such as a session time out or expiry warning.

❌ Prompting users to complete unrelated tasks

Asking a user to complete their profile when viewing customer information and potentially on the phone to a customer isn’t good for anyone.

❌ To display large amounts of data

Modals by design are often smaller than the main page. Therefore they are less than ideal when you need to display a large amount of data.

❌ To display error messages

Don’t use a modal to display error or success messages relating to actions performed on the main page.

❌ To display long forms

Space is limited so displaying a long form in a modal should be avoided. Consider breaking the form down into simpler steps and the use of a multi-stage modal.

❌ When another modal is already is view

Spawning a modal from another modal or showing additional modals when one is already displayed should be avoided. Multiple modals are confusing for the user and create accessibility and usability issues.

❌ To capture data unrelated to the users’ actions

Don’t fall into the trap of using modals for everything. Very often, directing the user to a different page is the right solution. Use modals sparsely to enhance the experience.

Designing the perfect modal

A poorly designed modal can be confusing to the user and make task completion harder. Consider the following when designing:

Obvious exit route

Provide obvious ways to close the modal. Typically a large X button in the top right and a cancel button (cancel rather than close as the user is cancelling the action that triggered the modal). The ESC key should also close the modal.

Clear and descriptive title

Give the user context on the modal’s function. The title should match or be very closely related to the button that triggered the modal. For example, when the triggering button text is ‘New Customer’ the modal title should be ‘New Customer’ or similar.

Clear calls to action

The modal should focus on allowing the user to perform one task. The call to action button should reflect that. A modal’s action buttons should be written so that if a user only reads the buttons, they get an idea of the action they’re about to perform instead of blindly clicking ‘OK’ or ‘Confirm’.

Background overlay

The overlay should be dark enough to draw the user’s attention to the modal but light enough so that the user knows they are still on the same page, but access to the page is blocked by the modal. Too light and the modal may not be obvious, too dark and the user may not know they are still on the same page.

Smaller viewport widths

At smaller viewport widths the modal should be either full screen or almost full screen to maximise on available space and make the content easier to read.

States

Consider how the modal may be used. If it’s likely to be highlighting destructive or dangerous actions, then the styling should reflect that.

Accessibility

There are some additional accessibility considerations to take into account when designing modals.

Focus management

In order to meet the WCAG 2.4.3 Focus order success criterion, the following should be done.

1. Focus should be shifted inside of the modal and set on the first interactive element.
2. Focus/keyboard navigation should be trapped within the modal.
3. The user should not be able to interact with the page behind the modal or navigate to it via the keyboard.
4. Ensure the user cannot navigate via the keyboard to elements inside the modal when the modal is closed.
5. If the modal is closed via the Cancel button, the X button or pressing ESC focus should return to the element that triggered the modal.

ESC button

Pressing the escape button should close the modal.

Clicking the body to close

Many articles suggest that clicking the background overlay should close the modal. However, I’d advise against this. In user testing, this behaviour frustrated and confused users, especially if they were switching between different app windows where there’s an increased chance of the user clicking the background overlay to refocus the window and therefore close the modal (frustrating if you’re midway through a form).

ARIA (Accessible Rich Internet Applications)

Various ARIA attributes should be added to the main modal element to assist users of screen readers and other assistive technology.

• Adding role="dialog" allows assistive technology to identify that the element is the modal container.
• Adding aria-modal="true" tells assistive technology that the window underneath the modal is not available for interaction.
• Adding aria-labelledby="<modal-title-ID>" gives the dialog an accessible name by referring the element that provides the dialog title. Without this, when an input is focussed within the modal, a screen reader will only read the input label. With this, it will also read the modal title giving more context to the user.

More information on accessible modals can be found at the WAI ARIA modal example.

Closing thoughts

Modals, when used correctly, can allow users to quickly perform actions without losing context or changing pages. Be wary of how you implement them as poorly done; they can create confusion and become a hindrance.

The UIs above were built with the Pulsar design system which delivers the bulk of this functionality to the Jadu Continuum Platform.

Liked this post? Let me know what other aspects of modern enterprise UI design you’d like me to cover in the comments below.