Implement correctly
Build Segmented control without breaking its behavior
# Implement Segmented control in your agent ## Objective Implement Segmented control for this verified behavior: A visually joined group of adjacent options that selects one value from a small set. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Segmented control 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 - Comfortable density selected - Compact density selected - Dense density selected ## Accessibility - ARIA role: radiogroup > radio - The primary control or named region for Segmented control has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The group is one tab stop after selection, with a visible focus indicator distinct from selected state. - Not applicable: choosing another segment replaces the selected value. - The group name, each option name, and selected state are exposed as a single-value choice. - Tab enters the selected segment - Arrow keys move and select - Space selects the focused segment ## When not to use - Each option reveals a substantial content panel - Labels are long or there are too many values ## Acceptance criteria - The control represents one value, not content panels - All labels remain short and readable - Focus and selected state are distinct - The compact layout has an explicit mobile fallback ## 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 Segmented control on a real journey
# Verify Segmented control after implementation ## Objective Audit the Segmented control 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:7ea95ffa43fd1d53504be54de2d79d39dfad8269d1e15a958ad3a7f292213c20