Implement correctly
Build Tabs without breaking its behavior
# Implement Tabs in your agent ## Objective Implement Tabs for this verified behavior: A set of labels that switches between related content panels while keeping one panel visible at a time. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Tabs matches the need before writing code. ## Required behavior - The selected tab exposes its associated panel while the other panels are hidden. - Arrow keys move through related items according to their visual orientation. ## States to cover - Overview tab selected - Files tab selected ## Accessibility - ARIA role: tablist > tab + tabpanel - The primary control or named region for Tabs has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The tab list is one tab stop; the visible panel is reachable in normal document order when it contains focusable content. - Not applicable: selecting another tab replaces the visible panel without closing the component. - Selected state and the relationship between each tab and its named panel are exposed. - Tab enters the selected tab - Arrow keys move between tabs - Enter or Space activates in manual mode - Home and End reach the first and last tab ## When not to use - Users need to compare panels simultaneously - Each destination deserves its own URL and page navigation ## Acceptance criteria - Every tab controls exactly one panel - Only one peer panel is presented at a time - Arrow and activation behavior is documented - Slow panels use manual activation ## 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-tabs
- 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 Tabs on a real journey
# Verify Tabs after implementation ## Objective Audit the Tabs 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:0d11cfd83f56f5d408108b8dc5e118b801fbe00da1c4741476df6eba9c9a8f82