Implement correctly
Build Banner without breaking its behavior
# Implement Banner in your agent ## Objective Implement Banner for this verified behavior: A prominent, persistent message spanning a page region to communicate a condition that affects broad page use. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Banner 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 - Maintenance announcement inactive - Maintenance announcement active ## Accessibility - ARIA role: section | aside - The primary control or named region for Banner has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The banner appears before main content without stealing focus; links receive the same visible focus as the rest of the page. - A close control exists only for noncritical notices, and dismissal persistence expires when the message changes materially. - A newly introduced urgent condition may be announced once, while persistent static content remains discoverable without repeated live announcements. - Tab reaches banner links in document order - Enter activates the details or dismiss action ## When not to use - Only one field or local task is affected - The message is a routine low-risk confirmation ## Acceptance criteria - The message truly affects a broad page region - The container is a named section rather than misusing role banner - Navigation and focus remain usable at narrow widths - Dismissal never hides an unresolved critical condition ## 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 Banner on a real journey
# Verify Banner after implementation ## Objective Audit the Banner 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:2d6bd385de9ce1245263a77330b0e67cdc3d2b6399839c59e629a5946d9cc7a5