Implement correctly
Build Data grid without breaking its behavior
# Implement Data grid in your agent ## Objective Implement Data grid for this verified behavior: An interactive tabular composite that manages one keyboard entry point and directional focus among cells, often adding editing or selection. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Data grid matches the need before writing code. ## Required behavior - Arrow, Home, and End keys move one managed focus point through the two-dimensional grid. - Activation or a documented edit command enters a cell control, then returns to grid navigation predictably. ## States to cover - Grid ready - Cell active - Cell editing - Row selected ## Accessibility - ARIA role: grid > row > (columnheader | rowheader | gridcell) - The primary control or named region for Data grid has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Use one consistent roving-tabindex or aria-activedescendant strategy, keep the active cell visible, and never put every cell in the page tab sequence. - The grid is not dismissed; Escape exits cell interaction and restores grid navigation. - The grid has a name; focus exposes row and column context, selection or editing state, and correct virtualized counts and indices. - Tab enters at one managed cell and a later Tab exits - Arrow keys move among cells; Home and End move within a row - Control+Home and Control+End reach grid bounds - Enter or F2 enters cell interaction and Escape returns - Selection shortcuts exist only for the declared model ## When not to use - The data is static and read-only - The team cannot implement and test composite focus completely ## Acceptance criteria - One cell or descendant is tabbable - Every Arrow destination is focusable and labelled - Edit mode has a clear entry and exit - Focus and selection look different - Virtualized indices and counts are exposed ## 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 Data grid on a real journey
# Verify Data grid after implementation ## Objective Audit the Data grid 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:a9623f01d42c632dad3cbf46bb98c1c895bb32bd07d5b905f049d4819e875cd9