Implement correctly
Build Table without breaking its behavior
# Implement Table in your agent ## Objective Implement Table for this verified behavior: A non-widget tabular structure that relates static data through rows, columns, and their headers. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Table matches the need before writing code. ## Required behavior - Native row and column headers give every data cell its reading context without managed widget focus. - Pointer, Enter, or Space activation runs one named action exactly once. ## States to cover - Unsorted - Sorted ascending - Sorted descending ## Accessibility - ARIA role: table > (thead | tbody) > tr > (th | td) - The primary control or named region for Table has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - Focus remains on the activated sort button when rows reorder; reading cells never gain managed widget focus. - A table is document content and is not dismissible. - The caption names the table, scoped headers provide every cell’s context, and aria-sort exposes the active sort direction. - Cells do not enter the Tab sequence - Tab reaches only controls or links inside the table - Enter or Space activates a focused sort button ## When not to use - Users need spreadsheet-like focus, editing, or selection - The structure is only visual layout ## Acceptance criteria - Use a native table whenever possible - Provide a caption or equivalent name - Scope header relationships correctly - Keep static cells out of Tab - Put sorting in a real button and update aria-sort ## 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 Table on a real journey
# Verify Table after implementation ## Objective Audit the Table 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:9ccc77211d4d03f97d1bf4fb8b195b93adb9eb35d4bf8c2cbb75b3b84c524403