Implement correctly
Build Switch without breaking its behavior
# Implement Switch in your agent ## Objective Implement Switch for this verified behavior: A binary control that exposes a setting as on or off. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Switch matches the need before writing code. ## Required behavior - Activation changes the binary state; when that value is persisted is a separate product decision. - The control keeps the same accessible name while its checked, on, or off state changes. ## States to cover - Setting off - Setting on ## Accessibility - ARIA role: switch - The primary control or named region for Switch has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The switch is one visible focus stop and its label activates the same control. - Not applicable: the setting persists until toggled again; a failed update restores the prior state. - The stable accessible name and current on or off state are announced after every change. - Tab focuses the switch - Space toggles on and off ## When not to use - The value is an independent checked choice rather than an on or off setting - The choice is one of three or more mutually exclusive values ## Acceptance criteria - The control exposes an unambiguous on or off state - The label stays constant when the state changes - On and off differ by more than color - Failure restores state and is explained in context ## 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-switch
- 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 Switch on a real journey
# Verify Switch after implementation ## Objective Audit the Switch 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:2df20edb8bb4f1f8d3d7943bd799b5e1143ae2a7c6ce2594ddb05504f3841df3