Keyboard navigation

Pass cellNavigation to navigate the whole table with the keyboard, spreadsheet-style. The table renders with the WAI-ARIA grid pattern: role="grid", a single Tab stop, and a roving tabindex, so the table adds exactly one stop to the page's Tab order and all movement inside it happens with the keys below. Navigation covers every cell, including the header row, selection checkboxes, and expander buttons, so sorting, selecting, and expanding all work without a mouse. It's independent of inline editing and works on read-only tables too.

<DataTable columns={columns} data={data} cellNavigation />;

All shortcuts

Arrow keys only navigate when the focused cell is not being edited. While an editor is open, arrow keys behave normally (moving the text cursor, changing a native<select>, etc.).

Movement: arrows, Home/End, Ctrl+Home/Ctrl+End

The base behavior works on any table, editable or not. Arrow keys move one cell at a time and clamp at the edges — there's no wraparound from the last column back to the first. Homeand End jump to the first / last cell in the current row; add Ctrl(⌘ on macOS) to jump to the first / last cell of the whole grid instead.

<DataTable columns={columns} data={data} cellNavigation />;

Sorting from the keyboard

Arrow ↑ out of the first body row to reach the header. On a sortable column,Enter or Space cycles the sort exactly like a click would — ascending, then descending, then back to unsorted. See Sorting for the full behavior, including multi-column sort.

const columns: TableColumn<Employee>[] = [
  { id: 'name', name: 'Name', selector: r => r.name, sortable: true },
  { id: 'department', name: 'Department', selector: r => r.department, sortable: true },
  { id: 'salary', name: 'Salary', selector: r => r.salary, sortable: true, right: true },
];

<DataTable columns={columns} data={data} cellNavigation />;

Editing from the keyboard

Enter or F2 opens the focused cell's editor if the column has one (editable or editor). Enter inside the editor commits;Escape cancels. Either way, focus lands back on the cell wrapper so arrow-key navigation continues without an extra click. See Inline editingfor the full set of editor types.

const columns: TableColumn<Employee>[] = [
  { id: 'name', name: 'Name', selector: r => r.name, editable: true, onCellEdit: handleCellEdit },
  { id: 'department', name: 'Department', selector: r => r.department }, // no editor
  { id: 'salary', name: 'Salary', selector: r => r.salary, right: true, editable: true, onCellEdit: handleCellEdit },
];

<DataTable columns={columns} data={data} cellNavigation />;

Selection and expansion from the keyboard

Selection checkboxes and expander buttons sit in the nav grid like any other cell. Arrow onto a row's checkbox and press Space to select it — arrow up far enough and you reach the header's select-all checkbox, which works the same way. Arrow onto an expander button and pressEnter to expand or collapse that row.

<DataTable
  columns={columns}
  data={data}
  cellNavigation
  selectableRows
  expandableRows
  expandableRowsComponent={RowDetail}
/>;

The grid pattern

Without cellNavigation, the table renders role="table" with plainrole="cell" cells — the right shape for a screen reader's native table-reading commands, since nothing in the table is meant to hold focus. Turning on cellNavigationswitches every region to the WAI-ARIA grid pattern: role="grid", role="gridcell" for body cells, and a single roving tabIndex={0} that follows the last-focused cell. This is why it's an opt-in prop rather than always-on — it's the right choice for tables you expect people to operate, not a strict upgrade over the default.

See Accessibility for the full ARIA role reference, including how roles differ with and without cellNavigation.

Limitations

• Clamps at row/column edges rather than wrapping.
• Doesn't cross page boundaries — arrowing past the last row does not auto-paginate.
• Key bindings are fixed. There's no prop to remap them.

Prop reference