Implement correctly
Build Listbox without breaking its behavior
# Implement Listbox in your agent ## Objective Implement Listbox for this verified behavior: A composite widget of named options that supports one or multiple selections and can be standalone or used as a combobox popup. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Listbox matches the need before writing code. ## Required behavior - Arrow keys navigate according to the declared control model; focus and selection states are exposed consistently, including when selection follows focus. - The control exposes whether one or multiple values can be selected and updates every selected state consistently. ## States to cover - Default preset selected - Last 30 days selected ## Accessibility - ARIA role: listbox > option - The primary control or named region for Listbox has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - The native sized select is one tab stop. In this single-select specimen, selection follows keyboard focus, so active and selected state move together; custom listboxes must declare their own model. - In this standalone specimen, leaving with Tab preserves the selected value; when a listbox is a popup, dismissal is coordinated by its owning control. - The list name, four-option count, selected state, disabled state, and this specimen's single-selection mode are exposed by native semantics. - Tab enters the composite control once - In this native single-select specimen, arrow navigation updates selection as focus moves - There is no separate commit command in this specimen - Platform-supported Home and End keys reach boundaries ## When not to use - Screen space is scarce and a native Select is sufficient - Items are commands instead of values ## Acceptance criteria - Options belong to one named list, whether standalone or used as a popup - The relationship between focus and selection is declared, including whether selection follows focus - Arrow, Home, and End behavior is consistent - The selection mode is explicit ## 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 Listbox on a real journey
# Verify Listbox after implementation ## Objective Audit the Listbox 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:1af496920d6ad89f44563ae70e70b921be1fc7525384891cd41d25fa930a50d6