skip to content

For a toast in a design system, how long should it stay visible, and what should pause or extend that timing?

level: middleimportance: must knowfreq 52%

answer

  1. reading time, not a fixed number
  2. hover and focus stop the clock
  3. actions change the rules
  4. no hover on a TV remote
  5. a user setting to keep them

basics

~20 s

Long enough to read comfortably, scaled to its length; the timer pauses while the toast is hovered or focused, and a toast with an action stays longer or until dismissed. Users should be able to keep toasts on screen.

solid answer

~50 s

A toast's duration is a **convention**, not a standard: a few seconds as a base plus time proportional to the text, so a longer message stays longer. The timer **pauses** while the pointer is over the toast or keyboard focus is inside it, and while the window is not visible, and restarts when the user leaves. A toast with an **action** such as 'Undo' either stays until dismissed or stays much longer, because keyboard, remote and screen-reader users need time to reach it; many practitioners treat that auto-dismissal as a time limit under WCAG 2.2 2.2.1 Timing Adjustable (Level A), which asks that users can turn off, adjust or extend it. The Authoring Practices alert page goes further and advises against alerts that disappear automatically at all. A global setting to keep toasts until dismissed covers everyone.

go deeper

for a junior

Recall that toast duration depends on text length and that hovering or focusing a toast pauses its timer.

for a middle

Explain the pause rules, why toasts with actions stay longer or until dismissed, and why the duration is a convention rather than a standard.

for a senior

Show how you would handle timing on a television with no pointer, and cite 2.2.1 and the Authoring Practices advice accurately without overstating them.

for a principal

Weigh auto-dismissal against persistence as a system default across web and television, and decide what the user preference controls.

## Why timing is the hard part A **toast** is a brief message that appears in a consistent place, confirms something, and goes away by itself. Going away is the point — it does not pile up — and also the risk: a message removed on a timer is gone before some users can read it. Users with low vision may be panning a magnified view; users with cognitive disabilities may read slowly; screen-reader users may still be hearing the previous sentence; a viewer on the sofa may be looking at the film, not the corner of the screen. ## How long: a convention with a reason No standard sets a toast's duration. Design systems pick a rule, and the defensible ones share a shape: - A **base duration** of a few seconds for the shortest message. - **Extra time per word**, so a two-line message is not given the same time as 'Saved'. - A **longer minimum** on a television, where text is read from across the room. - A **user setting** — at the system or app level — to keep toasts until dismissed. State it as the system's convention and its reason, not as a rule any standard mandates. ## What pauses or extends the timer | Event | Behaviour | Why | |---|---|---| | Pointer hovers over the toast | Timer pauses; resumes on leave | The user is reading or about to act | | Keyboard or remote focus enters the toast | Timer pauses | The user reached it deliberately | | App or window is hidden | Timer pauses | Nobody can see it | | Toast has an action | Stays much longer or until dismissed | The action must be reachable in time | | More toasts are queued | Timer starts only when shown | A queued toast has not been seen yet | ## What the standards say, and what they do not - WCAG 2.2 **2.2.1 Timing Adjustable** (Level A) covers each time limit set by the content: the user must be able to turn it off, adjust it to at least ten times the default, or be warned and extend it with a simple action. Whether an auto-dismissing toast is such a time limit is an interpretation; many practitioners apply it to toasts that carry an action, because the action becomes unreachable when the clock runs out. - WCAG 2.2 **4.1.3 Status Messages** (Level AA) requires that status messages — which a toast usually is — can be presented by assistive technology without receiving focus. That is about announcement, not duration. - The WAI-ARIA Authoring Practices **alert** page advises avoiding alerts that disappear automatically, noting that one which disappears too quickly can fail 2.2.3 No Timing (Level AAA). - WCAG 2.2 **1.4.13 Content on Hover or Focus** does not apply: a toast is not triggered by hover or focus on another element. ## Television and web: the same rule, different inputs On the **web player** of a video-streaming service, pause-on-hover and pause-on-focus are straightforward. On the **television app**, there is no pointer, and moving the remote's focus to a floating toast would pull it away from playback. Two consequences follow: 1. Television toasts should carry **no action**, or the action is reachable another way, because focus cannot reasonably travel to them. 2. Their duration leans longer, and anything the viewer must act on becomes a banner or a message on the relevant screen instead. ## Putting it in the spec 1. Duration formula and its reason, including the television minimum. 2. Pause on hover, on focus, and while hidden; restart on leave. 3. Toasts with actions: stay until dismissed, or at least a much longer duration, with the action also available elsewhere. 4. A setting to keep toasts until dismissed. 5. A dismiss control reachable by keyboard for toasts that stay. ## Common mistakes - A fixed short duration for every message regardless of length. - A timer that keeps running while the pointer rests on the toast. - An 'Undo' toast that disappears before a keyboard user can reach it. - A queued toast whose timer started before it was ever shown. - A toast that pauses on hover but not on keyboard focus, so keyboard users get less time than pointer users. The interview-grade answer names the duration as a convention with a reason, lists the pause triggers, treats actionable toasts as a special case, and cites the standards for what they actually say — neither claiming that WCAG fixes a number nor that it is silent on toasts altogether.

  • Does moving keyboard focus into a toast to pause it break the rule that toasts never take focus?
    No. The toast must not take focus by itself when it appears, because that interrupts the user. A user who chooses to move focus into it — to press 'Undo' — is acting deliberately, and pausing the timer then is exactly what they need.
  • Is it acceptable for a toast never to disappear on its own?
    Yes, and some systems choose it for toasts with actions or as a user preference. The cost is clutter, so such toasts need a clear dismiss control and a limit on how many can be visible, with the rest queued.

saying these in an interview costs you the question

  • Every toast should last exactly the same number of seconds.
  • The timer should keep running while the pointer rests on the toast.
  • An 'Undo' toast can vanish quickly; keyboard users can use the mouse.
  • WCAG sets a standard toast duration that all systems must follow.
  • A queued toast's timer should start when it is created, not shown.