Implement correctly
Build Checkbox without breaking its behavior
# Implement Checkbox in your agent ## Objective Implement Checkbox for this verified behavior: An independent binary choice that can be checked, unchecked, or sometimes indeterminate. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Checkbox matches the need before writing code. ## Required behavior - Activation changes the binary state; when that value is persisted is a separate product decision. - A parent choice can expose an indeterminate state when only some child items are selected. ## States to cover - Checkbox unchecked - Checkbox checked ## Accessibility - ARIA role: input[type=checkbox] - The primary control or named region for Checkbox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Each native checkbox is a visible focus stop and its label expands the pointer target. - Not applicable: the checkbox persists until the user toggles it or the form resets. - Accessible name, checked or mixed state, required state, and validation message are exposed. - Tab focuses each checkbox - Space toggles the focused checkbox ## When not to use - Exactly one option must be selected - The value is best expressed as an on or off setting ## Acceptance criteria - Every checkbox has a visible associated label - Independent options can be toggled separately - The mixed state is programmatic as well as visual - Space and pointer produce the same state ## 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 Checkbox on a real journey
# Verify Checkbox after implementation ## Objective Audit the Checkbox 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:fb445f68accc501656d510f4acd4d671b2a5badbd4540b5c3b7cdcf1141a157f