Designing Complex Tables & Data-Dense Interfaces

Q: Do data tables need ARIA?

Native HTML tables already provide semantics. Add aria-sort for sortable columns and live regions for updates; use the ARIA grid pattern only for interactive, spreadsheet-like tables.

Designing Complex Tables and Data-Dense Interfaces

Admin consoles, financial tools, CRMs, monitoring dashboards, and internal tools are built around tables: hundreds or millions of rows that people scan, sort, filter, compare, select, and act on in bulk. These interfaces serve experts doing repetitive work, so small design decisions compound: a misaligned number column slows every comparison, an unclear selection state causes someone to delete 1,284 records instead of 50, and a table that is not keyboard accessible excludes power users and screen reader users alike.

Good data-dense design is not about fitting more pixels on screen. It supports the tasks people perform — finding records, comparing values, viewing or editing a row, and acting on many rows — with clear structure, visible state, predictable interactions, and accessible semantics.

TL;DR

Use tables when people compare values across rows; use cards or lists for browsing heterogeneous items.
Right-align numbers with tabular figures, left-align text, and offer density options for expert users.
Make sort and filter state visible (sort indicators, filter chips, result counts) and easy to clear.
Choose pagination, load more, or virtualization based on tasks; keep selection and position stable.
Show selection state precisely: indeterminate header checkboxes, counts, and a clear distinction between "this page" and "all matching results".
Use real table semantics (<table>, <th scope>, aria-sort), support keyboard use, and design empty, loading, and error states.

Quick Example

Semantic markup for a sortable, selectable table with visible state:

Keeping the header checkbox truthful when some rows are selected:

Core Concepts

Tasks First

Data tables typically support four tasks: finding records that meet criteria, comparing data, viewing, editing, or adding a single row, and taking action on records. Identify which matter most for each table before choosing features — not every table needs column reordering, but almost every table needs clear filtering and sorting.

Columns and Formatting

Put the most identifying column first and consider sticky headers and first columns for wide tables. Offer density (comfortable, compact) for people who scan many rows.

Sorting, Filtering, and Search

Show the current sort with an indicator and aria-sort; define sensible default and secondary sorts.
Show active filters as removable chips with a "Clear all" control and an updated result count.
Distinguish "no data yet" from "no results for these filters", with a way out of the latter.
Keep filter and sort state in the URL so views can be shared and survive reloads.

For large data sets, sorting and filtering happen on the server; see Pagination, Filtering, and Sorting.

Paging and Virtualization

Libraries such as TanStack Table and TanStack Virtual handle the mechanics; the design must still keep position, selection, and focus stable as data changes.

Selection and Bulk Actions

Bulk actions are where data-dense interfaces cause the most damage. Make state explicit:

Indeterminate header checkbox when some rows are selected.
A selection count and a clear choice between "all on this page" and "all N matching results".
Selection that persists or resets predictably across pages and filter changes — and says which.
Bulk action bars that name the count ("Archive 50 invoices").
Undo or a specific confirmation for destructive bulk actions. See Content Design and UX Writing.

Editing and States

Inline editing suits quick, low-risk changes with clear save and cancel behavior and validation per cell; complex edits belong in a detail panel or page. Design loading (skeleton rows, preserved layout), refreshing (keep data visible), partial failure, and error states. See Loading, Empty, and Error States.

Accessibility and Keyboard Use

Use native table semantics: <table>, <caption>, <th scope="col"> and scope="row". Screen readers announce headers as users move between cells.
Use the ARIA grid pattern only when cells are interactive and need arrow-key navigation; it changes keyboard expectations and adds complexity.
Make sort controls buttons inside headers, update aria-sort, and announce result changes through a live region.
Ensure every control has an accessible name (row checkboxes naming the row) and a visible focus indicator. See Keyboard Navigation and Focus Management and Accessibility.

Responsive Strategies

Tables do not shrink gracefully. Options: horizontal scrolling with a sticky first column, prioritizing and hiding columns with a column chooser, collapsing rows into stacked cards on small screens (keeping labels), or a separate mobile view for the few tasks people do there.

Best Practices

Design for the Main Tasks

Prioritize finding, comparing, and acting for each table, and add features only where tasks need them.

Make State Visible and Shareable

Show sort, filters, and selection clearly, and keep view state in the URL.

Be Precise About Bulk Scope

Always show how many records an action will affect and whether it includes records on other pages.

Use Real Table Semantics

Start with native HTML tables and add ARIA grid behavior only for genuinely interactive grids.

Common Mistakes

Ambiguous Select-All

Left-Aligned Numbers in Proportional Fonts

Div-Based Tables

FAQ

When should I use a table instead of cards?

Use a table when people need to compare values across many items with consistent attributes. Use cards or lists when items are heterogeneous or visual, and comparison is less important.

Should numbers be right-aligned in tables?

Yes. Right-aligned numbers with tabular figures line up digits by place value, making comparison much faster.

Is infinite scroll good for data tables?

Rarely for task-oriented tables. Pagination or virtualized scrolling with stable positions usually works better for finding, comparing, and selecting records.

How should "select all" work in a paginated table?

Select all rows on the current page, then offer an explicit option to select all matching results, and show the selection count on every bulk action.

Do data tables need ARIA?

Native HTML tables already provide semantics. Add aria-sort for sortable columns and live regions for updates; use the ARIA grid pattern only for interactive, spreadsheet-like tables.