Implement correctly
Build Tree view without breaking its behavior
# Implement Tree view in your agent ## Objective Implement Tree view for this verified behavior: A composite widget for navigating hierarchical items whose parent nodes can expand or collapse their child groups. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Tree view matches the need before writing code. ## Required behavior - Up and Down move among visible items; Left and Right move across parent-child levels. - A parent item exposes or hides its child group while focus and selection remain distinct. ## States to cover - Tree idle - Collapsed parent focused - Expanded parent focused - Child focused - Child selected ## Accessibility - ARIA role: tree > treeitem + group - The primary control or named region for Tree view has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Use roving tabindex or aria-activedescendant consistently, and keep visible focus distinct from aria-selected or aria-checked. - The tree is not dismissed; Left Arrow collapses an open parent, and Escape is not a required tree command. - Each treeitem exposes its name, level, position, expanded state when it is a parent, and one consistent selection property; end nodes never expose aria-expanded. - Tab enters the tree once - Up and Down move among visible nodes - Right opens a parent or moves to its first child; Left closes or returns to the parent - Home and End reach the first and last visible nodes; type-ahead finds a matching node - Enter performs the default action and selection keys follow the declared model ## When not to use - Items form a flat list - Content is a static document outline or independent disclosures ## Acceptance criteria - The tree has an accessible name - Every node is a treeitem in the correct group - Only parents expose aria-expanded - One composite focus strategy is used - Focus and selection remain distinct ## 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 Tree view on a real journey
# Verify Tree view after implementation ## Objective Audit the Tree view 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:e0b1ec6b304aa4174ae6a1c3077283244ddbf9070ef67bdfdf429dda3a9638fc