Data Table Versus Interactive Grid

Working case

The operations queue has 62 rows and four columns. Reviewers only read most cells and open a case from one link, so a native table with clear column headers is enough. A later bulk-edit view allows changing status inside cells. That view may justify a grid, but every keyboard route must be designed and tested. If every cell becomes a Tab stop, reaching the next control can take hundreds of presses. If arrow keys are captured while editing text, a reviewer cannot move the caret. Choose one focus model and state transitions before attaching roles.

Implementation boundary

function shouldUseInteractiveGrid({ editableCells, directionalSelection }) {
  return editableCells || directionalSelection;
}
console.log(shouldUseInteractiveGrid({ editableCells: false, directionalSelection: false }));
// Output: false

The code is a decision gate, not an accessibility implementation. For a read-only view, render a semantic table with headers and a link or button where an action exists. For an interactive grid, manage one Tab entry point and directional movement inside it; update focus and active-cell state together. When editing a text cell, hand arrow keys back to the text control until the user exits edit mode. Announce row and column context, preserve a stable active cell when data refreshes, and avoid virtualizing the focused row out of the DOM. Test the complete keyboard path with a screen reader rather than relying only on an automated role check.

Cost and boundaries

Rendering n rows with c cells is O(n × c) DOM nodes; virtualization can reduce mounted nodes but complicates row positions, focus, and assistive-technology context. A native table has low interaction-code cost. A grid adds state, key handling, and test cases for edit mode, selection, and data refresh. That expense is justified by frequent cell-level operations, not by a desire for a spreadsheet appearance. Measure task time and keyboard effort with real row counts; reducing DOM work while losing the active cell is not an improvement.

Failure trace

A developer changes a table's outer role to grid and assumes screen readers will infer spreadsheet behavior. Arrow keys still scroll the page, while every nested button remains a separate Tab stop. Implement the grid contract or remove the role. Another defect occurs when a live sort removes the focused cell; focus falls to the document body and the next key acts elsewhere. Preserve active row and column identity through updates, or move focus to a clear fallback and announce that the row changed.

Verification

• Read-only rows retain correct header relationships.
• Grid mode has a documented entry, edit, and exit path.
• Sorting or virtualization does not discard focus silently.

Practice drill

Build a read-only 62-row queue with a real table and one case link per row. Test row and column announcements and count Tab stops. Then add an editable status cell and specify entry, editing, commit, cancel, and exit keys before considering a grid. Sort while the active cell is focused and verify a stable fallback. Render only a window of rows in a separate experiment, then test whether the active row remains mounted and total row context remains understandable.

Decision note

Use a table for comparison and reserve a grid for a real cell-level keyboard workflow you are prepared to implement.

Common Mistakes

• Adding role=grid without directional keyboard behavior.
• Making every cell a Tab stop in a large table.
• Capturing arrow keys while an input needs them for text editing.

Connected lessons

Complex Accessible Interactions; Combobox Suggestions and Active Option; Reorder Controls Without Dragging; Async Status Announcements and Focus; Accessible Names and Native Controls; Accessible forms: connect labels, errors, and focus; Search Filters and Result Cursors.

Apply and check

Build Project: accessible operations workspace and review Web Development: streams and interaction decisions quiz.

Further connections

Chart and Diagram Text Equivalents.