Implement correctly
Build Button without breaking its behavior
# Implement Button in your agent ## Objective Implement Button for this verified behavior: A named control that performs an action in the current interface when activated. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Button matches the need before writing code. ## Required behavior - Pointer, Enter, or Space activation runs one named action exactly once. - The content region exposes its busy state while a separate visual indicator remains redundant. ## States to cover - Save idle - Save pending - Save error - Save successful ## Accessibility - ARIA role: button - The primary control or named region for Button has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - A high-contrast focus indicator remains visible in every enabled visual variant and pending state. - Not applicable: an action button does not open a surface unless that separate relationship is defined. - Accessible name, disabled or pressed state when applicable, and pending result are exposed without changing the label ambiguously. - Tab focuses the button - Enter and Space activate it - Form submit behavior follows its explicit type ## When not to use - Activation primarily navigates to another URL - The control has no clear action name ## Acceptance criteria - The button performs an action rather than navigation - Its visible label states that action - Enter, Space, focus, disabled, and pending states work - Text contrast and target size meet the quality bar ## 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 Button on a real journey
# Verify Button after implementation ## Objective Audit the Button 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:e3ad88b2402fc89e324f39a708a5869e251812c4a777801dede95ecdf0634bb9