# Toast

A toast reports a brief result without interrupting the current task. It is not
appropriate for information that requires a decision, blocks progress, or must
remain available for later reference.

## Content and timing

State what happened and, when useful, what can happen next. Avoid generic
“Success” messages. Informational toasts may dismiss automatically only after
enough reading time; errors and recovery actions remain until dismissed or
moved to a persistent surface.

Queue messages to prevent overlap and repeated announcements. Deduplicate
identical events. A burst of background activity should produce a summary, not
one toast per item.

## Accessibility

Use a polite live region for routine updates and reserve assertive announcement
for urgent failures. The ARIA alert pattern defines no keyboard interaction, so
an alert alone cannot contain the only usable recovery path. If a toast includes
a dismiss or undo button, it must enter normal tab order without stealing focus.

Pause timed dismissal while pointer or keyboard focus is within the toast.
Respect reduced motion. Do not communicate status through color or icon alone.

## Placement and actions

Place the region consistently without covering primary navigation, form errors,
or system controls. Keep at most one short, reversible action such as Undo.
Consequential choices belong in a dialog or persistent page region.

## Verification

- Screen readers announce one message once.
- Focus stays on the initiating control unless the user moves it.
- Undo remains available for the documented duration.
- Hover, focus, zoom, safe areas, and virtual keyboards do not hide the toast.
- Multiple events queue or summarize predictably.
- Errors remain discoverable after the toast is gone.