Data grid

Problem Context

• The task involves many records with shared columns, and users repeatedly move across cells or down columns to compare, update, or triage values.
• Cells may contain editable values, links, menus, checkboxes, validation, calculated values, row actions, or status widgets.
• Users need keyboard-efficient navigation that avoids hundreds of tab stops while keeping cell identity and row context clear.
• The product may virtualize rows or columns, hide columns, sort, filter, pin, paginate, copy, paste, or save individual cell changes.

Selection Rules

• Choose data grid when row-and-column data is interactive enough to require managed cell focus, arrow-key movement, selection, editing, or keyboard shortcuts.
• Use a table when records are mainly read-only comparison and ordinary links, buttons, or checkboxes in row order are sufficient.
• Use inline edit when one displayed value or one row enters local edit mode without full spreadsheet-style navigation.
• Use tree grid instead of data grid when rows are hierarchical and expandable while still needing columns.
• Use list view, card list, or card grid when object summaries, imagery, or uneven metadata matter more than column-by-column work.
• Use transfer list when the task is moving items between sets rather than editing cells in place.
• Use pagination, infinite loading, or saved views to control very large row counts, but do not let paging erase grid focus, selection, or edit state.
• Avoid data grid when the task is a form with unrelated fields, section dependencies, or review-before-submit consequences.
• Avoid data grid when the team cannot implement and test keyboard navigation, focus movement, edit mode, row and column metadata, and screen reader behavior.
• Avoid forcing a dense data grid onto mobile when a list-plus-detail or focused edit route would preserve task accuracy better.

Required States

• Default navigation state with labelled grid, column headers, row headers or row identifiers, focused cell, and row count context.
• Focused-cell state that distinguishes focus from selection and survives movement across rows and columns.
• Selected row, selected cell, selected range, and bulk-selected states when selection is supported.
• Edit mode for a cell or row, with clear entry, focused editor, dirty draft, save, cancel, and validation states.
• Readonly or locked-cell state for cells that can be navigated but not changed.
• Sorted, filtered, grouped, hidden-column, and resized-column states with visible and programmatic state feedback.
• Virtualized, paginated, or lazy-loaded state with truthful total row and column counts, visible indices, and loading boundaries.
• Copied, pasted, invalid paste, undo, redo, saving, saved, failed-save, and conflict states when grid editing supports those actions.
• Empty, no-results, permission-restricted, and partial-data states that keep the grid label and recovery path visible.
• Narrow-screen or reduced-column state that preserves row identity, edit safety, and a route to the full task.

Interaction Contract

• Tab moves into the grid at one managed focus point and out to the next page control rather than visiting every cell by default.
• Arrow keys move focus between cells; Home, End, Page Up, Page Down, and modified Home or End commands move by row, viewport, or grid boundary according to the documented contract.
• The focused cell, selected cell, selected row, checked row, active editor, hover target, and row action are visually and programmatically distinct.
• Column headers that sort, filter, resize, pin, or open menus are reachable and announce their current state.
• Entering edit mode with Enter, F2, typing, or an explicit Edit command moves focus into the editor and temporarily changes how arrow keys are interpreted.
• Escape cancels editing or returns to grid navigation according to a visible and tested discard contract.
• Saving a cell, row, or pasted range keeps the edited location understandable after sorting, filtering, pagination, refresh, or server validation.
• Virtualization, hidden columns, frozen areas, and pinned rows must not make row or column indices, reading order, or focused-cell restoration untrue.

Implementation Checklist

• Define the grid purpose, row object, primary row identifier, columns, editable fields, readonly fields, selection model, and supported shortcut set.
• Choose native table plus role grid or ARIA row and gridcell structure only when the interaction truly behaves as a grid.
• Expose a label or labelled heading for the grid and a description for keyboard help, row count, filters, or selection status.
• Use row, columnheader, rowheader, and gridcell semantics, and provide aria-rowcount, aria-colcount, aria-rowindex, and aria-colindex when rows or columns are virtualized or hidden.
• Keep only the current managed cell or inner widget in the page tab sequence and update tabIndex as focus moves.
• Separate navigation mode from edit mode, including how Enter, F2, typing, Escape, Tab, arrow keys, and Save behave.
• Associate validation messages, dirty indicators, readonly state, and save errors with the affected cell or row.
• Preserve focused cell, selected rows, expanded detail, dirty edits, and scroll position across sort, filter, pagination, refresh, and column visibility changes where possible.
• Test with keyboard only, screen readers, high contrast, zoom, row virtualization, long values, pasted invalid data, mobile viewports, and assistive-technology reading order.

Common Generated-UI Mistakes

• Using role grid on a static table only to make it sound richer.
• Putting hundreds of inputs, menus, and links into normal tab order instead of implementing managed focus.
• Calling a dense settings form a data grid even though fields do not share row and column meaning.
• Letting arrow keys both navigate cells and operate the active cell editor without an edit-mode boundary.
• Hiding columns or virtualizing rows without row and column counts, indices, or truthful reading order.
• Using color alone for selected, dirty, invalid, readonly, and saved cell states.
• Sorting or filtering while a cell is dirty and moving it out of view before users can confirm the result.
• Packing row actions, nested menus, multiselect widgets, and expandable detail into cells without a tested focus strategy.

Critique Questions

• What does one row represent, and what is the primary row identifier?
• Which cells are navigable, editable, readonly, selected, invalid, dirty, or saving?
• Can a keyboard user enter the grid, move by cell, edit, cancel, save, select, copy, and leave without getting trapped?
• When does focus land on the cell itself versus an element inside the cell?
• What happens to focus, selection, dirty edits, and validation after sort, filter, pagination, virtual scroll, refresh, or save failure?
• Would a table, inline edit, list view, card layout, transfer list, or complex form solve the task with less interaction cost?