Markup that makes a table usable
A data table needs more than rows and cells to be comprehensible to a screen reader. Header cells must be <th> rather than styled <td>, and each needs a scope attribute — scope="col" or scope="row" — so assistive technology can announce the relevant headers as the user moves between cells. Without it, a cell is read as a bare value with no indication of what it measures.
A <caption> gives the table a name, announced when a screen reader encounters it and used when navigating between tables on a page. It is far more useful than a heading above the table, because it is programmatically associated.
Grouping rows into <thead>, <tbody> and <tfoot> conveys structure and has a practical benefit: browsers repeat <thead> at the top of each printed page. For complex tables where a cell relates to headers that scope cannot express, headers and id attributes make the relationship explicit — though a complex table is usually better split into several simple ones.
Never use tables for layout
Layout tables were standard practice in the 1990s and are now a genuine accessibility failure. A screen reader announces a table and its dimensions, then reads cell by cell — so a page laid out in a table is announced as a data structure with no data, and navigation commands intended for tabular data produce nonsense.
Grid and flexbox do everything layout tables did, with less markup and responsive behaviour that tables cannot match. The one legitimate exception is HTML email, where client support is so poor that table-based layout remains necessary — and there the tables should carry role="presentation" so assistive technology ignores their structure.
The converse mistake matters too: building a data table out of <div> elements because it is easier to style. That discards all the semantics, and rebuilding them with ARIA roles is more work than using the right elements. If the content is tabular, use a table.
Tables on small screens
Tables do not fit narrow viewports, and every solution is a compromise. Horizontal scrolling is the simplest and preserves the structure entirely: wrap the table in a container with overflow-x: auto. Make the container focusable with tabindex="0" and give it an accessible name, otherwise keyboard users cannot scroll it.
Reflowing each row into a stacked block works for tables with few columns, using a data attribute on each cell to display its header via CSS. It reads well on a phone and breaks down entirely for wide tables, where the stacked result is enormously long.
Prioritising columns — hiding less important ones below a breakpoint — keeps the table shape but withholds data, so it is only acceptable if the hidden columns are genuinely secondary or can be revealed. Whichever approach you choose, resist reducing font size to fit: text below about 16 px triggers zoom on iOS and is hard to read, which trades one problem for a worse one. For alignment, right-align numbers so digits line up by place value, left-align text, and use tabular figures where the typeface offers them so columns of numbers do not shift.