Implement correctly
Build Toast without breaking its behavior
# Implement Toast in your agent ## Objective Implement Toast for this verified behavior: A brief nonblocking message that appears after an event and may disappear after enough reading time. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Toast matches the need before writing code. ## Required behavior - The transient message may disappear after enough reading time and never blocks a critical decision. - A live region announces new status only when the update is important and not already focused. ## States to cover - Toast hidden - Toast visible ## Accessibility - ARIA role: status - The primary control or named region for Toast has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The toast never steals focus on arrival; an optional action becomes reachable without disrupting the current task. - It expires after sufficient time, pauses for interaction, and can be dismissed explicitly without requiring action. - A polite live status announces new text once; critical or repeated failures use persistent in-context messages instead. - Tab reaches a toast action only through normal order - Escape dismisses the focused toast when supported ## When not to use - The message contains critical recovery instructions - A decision or form error must remain visible ## Acceptance criteria - The toast never carries a critical decision - Arrival does not move focus - Reading time pauses during interaction - Stacked messages and their actions remain usable ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- @radix-ui/react-toast
- Requires · Access to the repository, design system, and tests
Why it works
- The need is tied to canonical behavior before any technical choice.
- States, accessibility, and non-goals prevent a merely visual implementation.
- Acceptance criteria and the output format make verification observable.
Try next
Verify Toast on a real journey
# Verify Toast after implementation ## Objective Audit the Toast implementation against its behavior, states, and accessibility requirements without changing it automatically. ## Checks - Replay the smallest representative journey. - Check keyboard behavior, focus, accessible name, and announcements. - Tie each gap to a specific acceptance criterion. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:8ac62b5f3297f11d1be2449b2d5f00e3d6eb17a686211116d03c2fe1fa3bd081