# Table

Use a table when rows and columns encode relationships that users compare.
Cards or lists are better when each item has a different structure or the
layout cannot preserve meaningful columns.

## Semantics and structure

Use native table elements for tabular data. Provide a caption or nearby labelled
heading, header cells with correct scope, and text equivalents for status icons.
Keep column labels concise and include units in headers when they apply to the
whole column.

## Interaction

Sorting controls are buttons inside headers and expose the active direction.
Selection uses labelled checkboxes and a clear selected-count summary. Row
actions must be keyboard reachable without turning a row containing multiple
controls into one nested link.

For editable tables, define save, validation, cancellation, conflict, and undo
behavior. Do not commit on focus loss unless that consequence is explicit and
recoverable.

## Responsive and large data

Choose deliberately among horizontal scrolling, priority columns, a detail
view, or a transformed list. Do not stack cells without retaining their header
labels. Sticky headers and columns must preserve readable layering and focus
visibility.

Virtualization requires stable row identity, retained focus, and tested
screen-reader behavior. Server-side sorting/filtering must describe the actual
result set and cancel obsolete requests.

## Data presentation

Align numbers consistently, use tabular numerals where comparison benefits, and
include units. Format dates and numbers for locale while preserving an
unambiguous machine value for export. Color-coded states need text or icons.

## Verification

Test no rows, one row, many rows, long values, missing values, sort, selection,
edit conflict, loading, retry, horizontal scroll, zoom, keyboard, screen reader,
and copied/exported data.