CategoryProduct design

Modal dialogs: when to interrupt and how to let people out

7 min read

Use a modal dialog only when stopping people prevents real damage or when you’re missing a piece of information their task can’t go on without. Everywhere else, a message on the page itself or a window that doesn’t block the background does the job at a lower cost (NN/g, Modal & Nonmodal Dialogs). When a modal does show up, it needs a visible close button, the Esc key and focus returned to wherever the person left off.

What makes a dialog modal

A modal dialog sits on top of the content and locks the rest of the screen until the person responds. A nonmodal one also sits on top, but you can keep using the page underneath. The classic example is the Gmail compose window, which stays in a corner while you look up an older message (NN/g).

There’s a third name in between. When the background is dimmed, the window is called a lightbox, and it’s usually modal, though not always (NN/g, Popups). The dimming is just visual. What makes it modal is that the background stops responding.

When the interruption is worth it

Every modal has a price. People drop what they were doing, read, decide, close it and then have to remember where they were. The 2017 NN/g article lists the cases where that price pays off (NN/g):

  • Preventing a loss that can’t be undone. Quitting without saving or overwriting a file justifies stopping someone.
  • Asking for something the task needs to continue. The example is asking for a login when someone tries to save a favorite while signed out.
  • Breaking a long task into steps. It works, but if the task has lots of steps, it probably deserves a full page.
  • Asking a short question that saves work later. Only when the question relates to what the person just did.

The same piece points out where modals get in the way. A newsletter signup isn’t critical to the visitor. A window in the middle of checkout distracts at the most delicate moment of the purchase. A decision that depends on information hidden behind the window itself doesn’t belong in it either.

Form errors stay out for the same reason. People need to see the message while they fix the field, so the error goes right next to it, as I cover in the post on form field errors.

When it turns into noise

In 2019, an NN/g researcher logged every popup she ran into on websites and apps over several weeks. It averaged 25 a week (NN/g, Popups). The article collects the patterns that annoyed people most in testing:

  • a popup before the page has loaded;
  • a popup right after login, when the person already has the next step in mind;
  • an email request before any interaction;
  • a rating request before the person has done anything worth rating;
  • several popups stacked one after another.

The cost goes beyond annoyance. Once people get used to closing useless windows, they close all of them without reading, including the one with a serious warning. That’s why the same article suggests showing critical warnings on the page itself, in a block that stands out (NN/g).

Google reaches a similar conclusion from another angle. A window covering the content makes it harder for search engines to understand the page and can hurt search performance. Its advice is to swap the full-page window for a banner that takes up only part of the screen (Google, intrusive interstitials and dialogs).

How to let people out

A 2015 NN/g article on overlays starts from three rules many designers already know (NN/g, Overuse of Overlays). They’re a visible close button, a dimmed background to show the page behind isn’t active, and closing with the Esc key. Then it shows what’s usually missing:

  • An explicit cancel. Many people don’t know that clicking outside closes the window. On touchscreens, others close it by accident.
  • Saved input. If the window had fields and got closed by mistake, whatever was typed should still be there when it reopens.
  • The Back button. By default, it doesn’t close the window. It goes to the previous page, and someone who only wanted out of the window loses the whole page.
  • A higher position. A centered window can get cut off at the bottom on short screens. Closer to the top, it shows up whole more often.

Phones and screen magnifiers make all of this worse. With the screen zoomed in, people see only part of the window and may never find the close button.

What the browser already does for you

The HTML <dialog> element, opened with showModal(), handles a good share of this work. It’s worked in every major browser since March 2022 (MDN, the dialog element). The dark background comes from the ::backdrop pseudo-element, which only exists when the dialog is opened as a modal.

A web.dev guide covers the rest (web.dev, building a dialog component). The Esc key closes the dialog without any code of your own. The rest of the page goes inert, with no clicks and no focus. On open, focus moves to the first focusable element inside the dialog. On close, it goes back to the button that opened it.

The W3C pattern for modal dialogs fills in the list (W3C, Dialog (Modal) Pattern). The Tab key cycles only through the controls inside, and the dialog needs a name, either visible or in aria-label. The pattern also recommends a close button that the keyboard can reach.

The same pattern carries a warning. Marking a window as modal when it doesn’t really lock the background misleads screen reader users, who stop perceiving the rest of the page. If the window doesn’t block, it shouldn’t be announced as modal.

How I built it on kahue.net

The screen gallery on each case study, like the one in the Vexor case, is a modal. It uses the native <dialog>, opened with showModal(), and it has its own name for screen readers, such as “Vexor gallery”. The first button inside it is the close button, so that’s where focus lands when the gallery opens.

A modal makes sense there because the person asked for it. They clicked a thumbnail to see the screen bigger, and the task inside the window is a single one: look at the screens and go back.

There are four ways out. The close button in the corner, the Esc key, which comes from the browser, and a click on the dark background, which I wrote separately. A click on the image itself doesn’t close it, so nobody loses the gallery by tapping the screen. The previous and next arrows sit at the bottom, within thumb reach, and the keyboard arrows switch images too.

The language switcher at the top of the site takes the opposite route. It isn’t modal: it opens a short list and leaves the rest of the page free. It closes on an outside click, on Esc or when the page changes. When Esc closes it, focus goes back to the switcher button. Hovering doesn’t open the list, because that created two states fighting each other.

What’s missing, going by the NN/g list, is the Back button. Right now, with the gallery open on a computer, it leaves the case page instead of closing the gallery.

Where the sources disagree

The friction point is the cookie notice. The 2019 NN/g article accepts a popup before the content when the law requires asking for consent (NN/g). In the same article, though, its advice for cookie notices is a nonmodal window at the bottom or side of the page.

Google exempts legally required windows, like age verification, from its interstitial rules. Even so, it asks that the content still load underneath and that the site not redirect to a consent-only page (Google). Both sources meet at one point: a legal requirement doesn’t call for a window that locks the whole page.

The common mistake: a modal instead of a page

Sometimes a modal exists out of convenience. Building a new page takes more work, and a window on top looks like a shortcut. NN/g lists that reason, avoiding a new page template, as one that doesn’t justify an overlay (NN/g).

The warning sign shows up early. If the window’s content needs a scrollbar, internal links or its own address to share, it’s already a page (NN/g). Giving it a page brings back normal scrolling, the Back button and a link people can save.

Sources

More articles

See all articles