Start With Table Semantics
Use a real table for tabular relationships, with a caption where context is not already clear, scoped headers and accessible names for controls. Do not turn a data grid into an unlabeled collection of generic div elements.
7 minute read · Updated 2026-09-05
Designing Accessible Data Tables for Admin Applications
Practical requirements for the screen where most back-office work actually happens.
The Direct Answer
An accessible data table needs semantic headers, clear labels, keyboard-operable controls, visible focus, announced sorting, meaningful selection and responsive behaviour that preserves relationships between labels and values.
Make Operations Understandable
Sort controls should announce direction. Row selection needs a label tied to the record. Bulk actions should state how many records they affect and remain unavailable when nothing is selected.
Design Every Data State
Loading, empty dataset, no filter results, partial data, permission restrictions and errors communicate different situations and require different recovery actions.
Preserve Meaning on Small Screens
Horizontal scrolling can be appropriate for comparison-heavy tables. A card transformation can work for record lists, but only if field labels remain present and action order stays predictable.
Frequently Asked Questions
Should every record list use a table?
No. Use tables when users compare the same fields across records. Use cards or lists when scanning identity and one primary action matters more.
Is horizontal scrolling accessible?
It can be when the region is keyboard reachable, clearly indicated and does not trap focus. Test it with keyboard and screen-reader workflows.
Where should row actions appear?
Keep frequent actions visible when space permits and group secondary actions in a consistently named menu. Do not rely on hover alone.