Component contract
What it must accomplish
Make system change, success, warning, or failure understandable without interrupting unnecessarily.
InformationalSuccessWarningErrorProgressDismissed
Usage
Choose the control by behavior
Use it when
- An action or background process changes state
- The person needs confirmation or recovery
- Urgency can be matched to an inline, banner, toast, or persistent surface
Use another pattern when
- The message duplicates visible page state
- The user must decide immediately; consider a dialog
- A disappearing toast would hide required recovery
Anatomy
Stable parts create a reliable contract
- 1Status icon or cue
- 2Message
- 3Optional detail
- 4Action
- 5Dismiss control when appropriate
Explanation
Interaction and keyboard behavior
- Actions and dismiss controls are reachable
- Focus is not moved for routine passive messages
- Persistent errors provide a direct recovery route
Why this matters
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Cross-system baseline
Accessible behavior
- Use appropriate live-region politeness
- Do not announce the same message repeatedly
- Never rely on color alone
- Keep actionable errors available until resolved
Responsive considerations
Adapt the decision—not only the dimensions
Allow messages and actions to wrap without covering critical controls. Avoid stacking transient messages until they fill a small viewport.
Content considerations
Language is part of the component
- Lead with what happened
- State whether work was saved
- Offer the next action
Common mistakes
Patterns that weaken the experience
01
Using success toasts for every click
02
Auto-dismissing errors
03
Moving focus to passive feedback
04
Showing internal error codes alone
Comparison
What to study across systems
Systems vary in names—toast, snackbar, inline notification, banner—but scope, persistence, and recovery are the meaningful decisions.
Open comparison