Responsive Data Table Disclosure Contract

Large Theory

Tables are good for data that needs row/column comparison, but they often fail on mobile, screen readers, keyboard navigation, and batch actions. Healthy table design starts by naming what users compare, then defines columns, sorting, filtering, row actions, batch actions, and mobile alternatives. Not every desktop table should become a horizontal scroller on phones.

Small Points

1. Every table needs a caption/title, primary object column, column headers, and necessary scope/headers relationships. Do not use tables for layout.
2. Column priority comes before styling: primary, secondary, optional, detail-only, and action. Mobile preserves primary/secondary while moving the rest into expanded detail or card rows.
3. Horizontal scroll can work for wide tables, but it needs clear shadows/hints, fixed first column or row heading, keyboard access, and unclipped focus rings.
4. For many mobile tables, a nested list or card row is more logical: the primary key becomes the first-level item and key fields become property rows.
5. Batch action mode and row action mode should not compete for focus; once rows are selected, row overflow and single-row buttons are de-emphasized or disabled.
6. Empty, loading, no-permission, no-results, partial-failure, and export states belong to the table contract.

Design Judgment

The table contract works only when users can compare columns on desktop, identify each object and key field on mobile, have header relationships read by screen readers, and complete sorting/filtering/selection/actions with the keyboard.

Implementation Notes

Create a table contract: caption, rowKey, primaryColumn, columnPriority, sortableColumns, filterModel, selectionMode, batchActions, rowActions, mobileMode(table-scroll/card-list/nested-list), emptyStates, and ariaDescription. In React, do not fake data tables with div grids. If virtualized or data-grid components are used, additionally verify aria-rowcount, aria-colcount, focus retention, and screen-reader behavior. Mobile card mode should share the same data source and permission logic rather than duplicating behavior.

Counterexamples/Risks

A 12-column table becomes 9px text on mobile; header and body horizontal scrolling desynchronize; sort icons lack aria-sort; batch selection still allows single-row delete; card mode drops column labels; exported results do not match current filters; the table lacks a caption so screen-reader users do not know its scope.

Case Study

The W3C WAI table tutorial emphasizes structural markup that associates headers with data cells. WAI mobile responsive table guidance suggests transforming many tables into nested lists on mobile. Carbon Data Table usage separates sorting, batch actions, row actions, and hover/focus behavior. The reusable lesson is that table design is not only visual grid work; semantics, responsive recomposition, and action mode are one contract.

Source Links

W3C WAI Tables Tutorial: https://www.w3.org/WAI/tutorials/tables/ WAI Responsive Data Tables: https://w3c.github.io/wai-mobile-intro/mobile/responsive-tables/ Carbon Data Table Usage: https://carbondesignsystem.com/components/data-table/usage/ GOV.UK Table Component: https://design-system.service.gov.uk/components/table/