Modals, Toasts and Tooltips: When to Use Each in UI

The short answer

All three patterns show something on top of the interface, but they differ in how strongly they interrupt the user:

• A modal blocks the rest of the interface. Use it when work cannot continue without the user's answer or when a mistake would be costly.
• A toast (snackbar) appears for a few seconds and does not get in the way. Good for confirmations: "Saved", "Email sent".
• A tooltip shows a short explanation of an element on hover or focus. Use it when information is helpful but not essential.

The rule: the more a pattern interrupts, the less often you should use it.

Comparison by urgency and interruption

Inline messages and banners are often a better alternative to modals: they do not cover content and stay where the user expects them.

Rules for modals

• One task. A modal is not a page. If tabs and scrolling appear inside, make it a separate screen.
• Clear buttons. Instead of "OK / Cancel", name the action: "Delete project" and "Keep it".
• Dismissal. A close button, the Esc key and, for non-destructive dialogs, clicking the backdrop. For dialogs with unsaved data, ask before closing.
• No chains. A modal on top of a modal is confusing. Rework the flow.
• Not on page load. A dialog that appears before the user has done anything feels like an obstacle.

Rules for toasts

• Display time depends on text length: a short message needs a few seconds, a longer one needs more. Pausing on hover and focus is a must.
• An "Undo" action in a toast beats a confirmation modal for reversible operations.
• Stacking. Put new toasts in one area, limit how many are visible at once and merge repeated messages.
• Position should be consistent: one corner or edge that does not cover key buttons or mobile navigation.
• Not for critical info. If the message must not be missed, a toast is wrong: it disappears while the user is looking elsewhere.

Rules for tooltips

• Show on hover and keyboard focus, hide on Esc.
• Text is one short phrase. No links or buttons inside — they are hard to reach.
• Touch screens have no hover. Put important explanations in visible text nearby or behind a separate help icon on tap.
• A small delay before showing prevents flicker as the mouse moves across the screen.

Accessibility

Modals:

• Focus moves into the dialog on open and returns to the triggering element on close.
• Focus trap: Tab must not escape into the content behind the dialog.
• Use role="dialog" (or alertdialog for critical confirmations), aria-modal="true" and a title via aria-labelledby.

The native <dialog> element with showModal() handles much of this for you:

<dialog id="confirm" aria-labelledby="confirm-title">
  <h2 id="confirm-title">Delete project?</h2>
  <form method="dialog">
    <button value="cancel">Keep it</button>
    <button value="delete">Delete</button>
  </form>
</dialog>

Place toasts in a live region (role="status" or aria-live="polite") so screen readers announce them without stealing focus. Use role="alert" for errors, but sparingly.

Link tooltips to their element with aria-describedby, and give icon-only controls an aria-label as well.

Detailed patterns are in the WAI-ARIA Authoring Practices Guide.

Misuse that annoys users

• A newsletter or discount modal one second after the site opens.
• A confirmation dialog for every small action — people start clicking "Yes" without reading.
• An error toast that disappears before it can be read.
• A tooltip as the only place where a required field is explained.
• A close button that is hard to find or hard to tap on a phone.
• Several toasts overlapping each other and the interface controls.