Implement correctly
Build Inline alert without breaking its behavior
# Implement Inline alert in your agent ## Objective Implement Inline alert for this verified behavior: A persistent message placed next to the content or task it explains, with urgency chosen from the actual update. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Inline alert matches the need before writing code. ## Required behavior - The message remains in context until the condition changes or the user deliberately dismisses it. - A live region announces new status only when the update is important and not already focused. ## States to cover - Upload ready - Upload size error ## Accessibility - ARIA role: status | alert | none - The primary control or named region for Inline alert has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The message does not steal focus on routine updates; failed submission may focus a summary or first invalid control deliberately. - It remains until the condition resolves; a close control exists only when hiding the message cannot conceal an unresolved risk. - New urgent errors use alert, routine status uses polite status, and static explanatory text needs no live role. - Tab reaches recovery actions in document order - Enter activates the named recovery action ## When not to use - A short low-risk confirmation needs no persistence - The condition applies to the entire page or site ## Acceptance criteria - The message sits beside the affected task - Text states the problem and a recovery path - Urgency determines the live role - The message persists while the condition remains ## 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.
- Web platform
- 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 Inline alert on a real journey
# Verify Inline alert after implementation ## Objective Audit the Inline alert 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:b23e966f4dec7254c8ee926a3815273e1874157adfa29f556023b2b3e446dbba