Design system Status and feedback
Toast
Brief, non-modal acknowledgement: what just happened, said once, gone on its own. Never the durable source of state.
.mk-toast-region.mk-toast.mk-toast.is-warning.mk-toast.is-error
Overview
A toast gives brief, non-modal feedback after an action. It says what happened, uses the matching system-feedback tone, then leaves on its own. The result itself must also remain visible on the page that owns it.
Usage
- Confirm the result of a recent actionUse a toast after the interface has already completed, partially completed, or rejected an explicit user action.
- Keep durable information on the pageA toast is transient and never becomes the only source of status, required follow-up, validation, or recovery instructions.
- Match the tone to the outcomeSuccess confirms what changed, Warning adds a brief caveat, and Error names what did not happen and where recovery remains available.
Anatomy
- 1Feedback icon. Repeats the result in shape; it never leaves the state to colour alone.
- 2Message title. A short result in stronger ink answers what happened before any detail.
- 3Message body. Optional supporting text gives one useful consequence or recovery step.
- 4State rail. The 3px leading edge carries the same functional tone as the icon and stays square against the surface.
Variants and states
| Variant | Specimen | Use |
|---|---|---|
| Success | Changes saved |
The requested action completed. Success is the default toast. |
| Warning | Saved with a warningOne item still needs attention. |
The action completed, but the resulting page contains a non-blocking condition worth noticing. |
| Error | Couldn’t save changesReview the page and try again. |
The requested action did not complete. The owning control or page also keeps the reason and recovery path. |
- Auto-dismissSuccess and warning leave after a short reading window. Error may remain slightly longer, but it is still not a blocking dialog.
- Stack newest firstOne fixed region owns concurrent messages; repeated results do not cover one another.
- No manual close by defaultA toast is brief feedback. If content must remain until acknowledged, use an inline message or dialog.
Do and don't
Success
Confirm the completed action in one direct result.
Do not celebrate, narrate the system or restate what the page already makes obvious.
Warning
Lead with the completed result, then name the non-blocking condition.
Do not use a vague warning that hides whether the action completed.
Error
Name the failed action and give the shortest useful recovery direction.
Do not make a transient toast the only explanation; keep the actionable reason beside the failed control.
Copy
- Name the result first“Changes saved” or “Couldn’t save changes” answers the reader before supporting detail begins.
- Use the past tenseThe toast reports what just happened; it does not label a future action.
- Keep one recovery stepIf recovery needs choices or a longer explanation, put it on the page or in a dialog.
Accessibility
- Use one polite live regionSuccess and warning announce without moving focus. Escalate only truly urgent failures.
- Keep focus where the action happenedA toast reports; it never steals the keyboard position.
- Repeat durable meaningAny state, error reason or required recovery remains available after the toast expires.
When to reach for something else
- The message belongs to a fieldUse inline validation beside the field so the reason survives and stays in context.
- The result changes a record stateUpdate the record's status or badge; the toast may only confirm that change.
- The reader must decideUse a dialog or an inline blocked-action reason; a toast cannot demand a response.
Markup
<div class="mk-toast-region" role="status" aria-live="polite">
<div class="mk-toast">
<svg class="ico" data-mk-icon="check" aria-hidden="true"></svg>
<span class="mk-toast-copy"><strong>Changes saved</strong></span>
</div>
<div class="mk-toast is-error">…failed result and recovery…</div>
</div>