Designing modals and pop-ups: when and how?

In short

A modal is the strictest kind of window. The page behind it can’t be used until it is closed. NN/g puts it briefly: modals interrupt users and demand an action.

Pop-up is a broader term. In everyday use it also covers newsletter windows, promo boxes and chat bubbles. On this page I cover both together, because the problems arise in the same place.

Cookie banners aren’t the topic of this page; other rules apply to them. There is a separate cookie banner pattern.

When to use a modal and when not to

The short answer: if the user has to make the decision at this moment, a modal; otherwise the page itself. Therese Fessenden’s NN/g article states the cost of a modal openly. A modal stops the current task and gives the user another goal. It can also hide important content and remove the context.

The same article names four cases where a modal fits. The first is warnings that prevent critical errors, the second information needed for the task at hand. Breaking a complex task into steps and asking a question that clearly saves the user work are on the list too. In the cards below, I sort the cases I meet most often into two groups: use and don’t use.

• Use

  Before an irreversible action

  “If you delete this address, it also disappears from your saved orders.” The moment when unsaved changes would be lost belongs here too.

• Use

  When a user’s task depends on missing information

  A user wants to save a product but isn’t signed in. Opening a sign-in window for them is an example.

• Don’t use

  For information unrelated to the flow

  Newsletter sign-up or a prompt to download the app are examples. They can sit on the page as a banner or card.

• Don’t use

  In the middle of a critical flow such as payment

  A promotional window at the payment step distracts and can shake the user’s trust.

Don’t show form errors in a modal either. NN/g recommends showing an error in a form on the page, next to where it occurred. How to write the error text is in the error messages pattern.

There is a separate warning for the payment flow. Fessenden recommends avoiding modals that interrupt high-stakes flows such as checkout. An unnecessary modal is distracting at best and shakes trust at worst. More ways to keep these steps simple are collected in the checkout pattern.

If no modal is needed, choose a non-modal window or an area on the page. Think of the window for a new email: while you write, you can keep reading the content behind it.

Timing: the pop-up on page load

The first problem is timing. According to Anna Kaley’s NN/g article, a pop-up that appears when the page loads interrupts users before they have seen any value. Kaley allows only one exception: when the site is legally required to collect cookie consent or verify age.

Kaley’s recommendation: show the pop-up once the content has become meaningful to the user. Ask about the newsletter after an article has been read. Open the feedback survey when the user has finished their main task.

Kaley names other common mistakes:

• A pop-up right after sign-in interrupts the user’s next step.
• Several pop-ups at once have to be closed one by one. Show only one window at a time.
• Instead of a survey in the middle of a critical task, a fixed feedback link at the edge of the page is enough.

Kathryn Whitenton says something similar at NN/g. According to her, it is safest to open the window after a user click or for truly urgent messages. One of her examples is a window that appears when the visitor is about to leave the site, and so doesn’t interrupt them.

There is the search side too. Google Search Central says that interstitials and dialogs that cover the content can lead to poor search performance. Instead, Google recommends banners that take up only a small part of the screen.

Ways to close: X, Esc and clicking outside

When you open a modal, make closing easy too. Whitenton explicitly asks for two things: a visible close command and the Esc key for keyboard users.

Closing by clicking outside can only be an extra way. According to Whitenton, many users don’t know it. On touchscreens the window can also close by accident, so add a Cancel button to windows that ask for information.

Drawing the cross small and faint is, in my view, often a deliberate choice. Close texts that shame users, such as “No, I don’t want a discount”, belong to the same family. I collect such tricks in the dark patterns guide. The sizes for the cross’s tappable area are in the touch target pattern.

Esc has an accessibility side as well. WCAG 2.2 success criterion 2.1.2 No Keyboard Trap is level A. According to the W3C’s explanation, keeping focus in a modal doesn’t violate the criterion as long as users know how to get out. The W3C names Esc as a commonly used standard exit method.

Focus trapping and returning focus

When a window opens, our eyes see it. Someone using a keyboard and screen reader, on the other hand, follows where the focus goes. The W3C’s WAI-ARIA Authoring Practices Guide (APG) describes this behaviour for a modal window:

1. On opening, focus moves inside. Usually to the first focusable element. With long content it can go to a static element at the top, and for an irreversible action to the least destructive option.
2. Tab cycles inside. On the last element, Tab moves focus to the first; on the first, Shift+Tab moves it to the last.
3. Esc closes.
4. On closing, focus returns to the element that opened it. If that element no longer exists, it goes to another one that fits the flow.

The APG also asks for role="dialog", aria-modal="true" and an aria-labelledby that points to the visible title. aria-modal should only be used when all interaction outside is really blocked and the area outside is visually obscured.

Today the browser does most of this itself. According to MDN, opening a <dialog> element with showModal() makes the rest of the page inert, and Esc closes the window. Focus goes to the first focusable element inside.

I always write the focus return myself, though. The small example below is enough for that:

<button type="button" id="open">Subscribe to the newsletter</button>

<dialog id="newsletter" aria-labelledby="newsletter-title">
  <h2 id="newsletter-title">Subscribe to the newsletter</h2>
  <button type="button" id="close" aria-label="Close">×</button>
  ...
</dialog>

<script>
  const open = document.getElementById('open');
  const d = document.getElementById('newsletter');
  open.addEventListener('click', () => d.showModal());
  document.getElementById('close')
    .addEventListener('click', () => d.close());
  d.addEventListener('close', () => open.focus());
</script>

Try it: bad modal, good modal

Both modals show the same newsletter box. The difference shows when you use them with the keyboard. Open the bad one first and press Tab, then compare with the good one.

With the bad modal, focus wanders over the buttons of the hidden page. A screen reader user may never hear that the modal opened. With the good modal, Esc, Close, Cancel and a click outside with an empty field close the window. Each time, focus returns to the button that opened it.

Full screen on phones

The small box in the middle of the desktop screen often causes problems on phones. Whitenton writes that windows whose close controls extend beyond the screen, or that prevent zooming, can lock the content completely. Disabling scrolling can also keep users from reaching the controls.

Fessenden’s article has an example too. A non-modal window on desktop becomes a full-screen modal on phones. The same component can behave differently depending on the screen. Design that deliberately from the start.

My preference: a modal with a form opens full screen on narrow screens. The title and close button sit at the very top, and the main button is full width. The good modal above behaves this way under 600 pixels. To keep the fields visible with the phone keyboard open, see the keyboard in mobile forms pattern.

My note

The most common modal problem in my audits is timing. As soon as you land on the home page, the newsletter window opens, and after you close it, the chat bubble appears. The user has closed two windows before seeing the product.

Next comes returning focus. The window opens cleanly and closes with Esc, but focus falls to the top of the page. Someone navigating by keyboard has to find their place again from the start.

The small cross is high on the list too. In the design file it is drawn as a small icon and stays that size in the code. On a phone, it takes several attempts with the thumb.

You don’t need a special tool to find this. Let go of the mouse and try to do your task in the window with only Tab, Shift+Tab, Enter and Esc. Then repeat the attempt on a phone with one hand.

And I recommend: before every new modal, ask whether the same content could sit on the page. In my experience, the answer is usually yes.

Checklist

Before I add a modal to a product, I go through this list. If you want me to review the windows in your product: the UX audit covers this.

• The modal opens for a decision the user has to make now.
• It doesn’t open on page load but after a user action.
• There is only one window at a time.
• There is a visible close button with a large enough tappable area.
• Esc closes the window.
• A window that asks for information also has a Cancel button.
• On opening, focus moves into the window.
• Tab and Shift+Tab cycle within the window.
• On closing, focus returns to the element that opened it.
• The window has a visible title, connected through aria-labelledby.
• On narrow screens, the close button doesn’t extend beyond the screen.