Implement correctly
Build Radio group without breaking its behavior
# Implement Radio group in your agent ## Objective Implement Radio group for this verified behavior: A named set of mutually exclusive choices where selecting one option clears the previous selection. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Radio group matches the need before writing code. ## Required behavior - Selecting one item automatically clears the previous item in the named group. - Arrow keys move through related items according to their visual orientation. ## States to cover - Standard delivery selected - Express delivery selected ## Accessibility - ARIA role: fieldset > input[type=radio] - The primary control or named region for Radio group has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The native group behaves as one tab stop once a value is selected, with visible focus on the active radio. - Not applicable: selection remains until another radio is chosen or the form resets. - The legend names the group, and each radio exposes its label, checked state, required state, and error relationship. - Tab enters the selected radio or first option - Arrow keys move and select - Shift+Tab leaves the group ## When not to use - More than one answer is allowed - The choice is better represented as an on or off setting ## Acceptance criteria - A visible legend names the whole choice - Exactly one option can be selected - Arrow-key behavior matches visual order - Required and error states apply to the group ## 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 Radio group on a real journey
# Verify Radio group after implementation ## Objective Audit the Radio group 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:82984a25671654eada61ce809e9c6dcdca96949925e28fa5073a125242875140