Start with the relationships in the data
A data table does more than place words and numbers in a grid. Its rows and columns explain what each value means. A person looking at a table may follow those relationships by position; a person using a screen reader may navigate from cell to cell and rely on header information to provide the same context. If the relationships are missing from the markup, a value such as “12” can become difficult to interpret.
Use a table when readers need to compare information across rows or columns, not simply to arrange a page visually. For example, a community workshop schedule might have columns for session, location and start time. Each row then represents one session. Before building the table, check whether its structure can be described in a sentence. If the information is really a series of independent descriptions, a list or separate cards may be clearer.
Give the table a clear name and real headers
A short caption tells readers what the table covers before they encounter its cells. “Workshop schedule by session, location and start time” is more helpful than “Schedule.” A heading above the table can introduce the surrounding section, but a caption stays associated with the table itself. Keep it specific enough to distinguish the table from others on the page.
Mark column labels as header cells rather than styling ordinary cells to look bold. For a straightforward table, identify column headers with scope="col". If the first cell in each row names that row, mark it as a header with scope="row". In the workshop example, “Start time” is a column header and “Intro to digital maps” might be a row header. This structure gives assistive technology a way to connect a data cell to the labels that explain it.
Keep header text concise but understandable on its own. “Location” is clearer than “Loc,” while “Start time” is more precise than “Time” if the table also includes an end time. Put units where readers can find them, such as in a header labeled “Duration (minutes),” rather than expecting them to infer what every number represents.
Keep the structure as simple as the task allows
Tables with merged cells, several header levels or irregular rows can be hard to follow, particularly when someone navigates one cell at a time. Simplifying the data often helps everyone. Instead of one large table with different kinds of information packed into it, consider two smaller tables with separate captions. Repeat a meaningful label where needed rather than leaving a cell blank because the value looks obvious on screen.
Some datasets genuinely need grouped columns or multiple levels of headers. In that case, make each grouping clear and ensure data cells are associated with the relevant headers; more complex associations may require explicit header IDs. Do not add complexity merely to reproduce the appearance of a spreadsheet. Likewise, avoid using empty cells, spacing characters or a table nested inside another table to control the layout. Those choices can make the reading order and relationships harder to understand.
Make small-screen views preserve context
On a narrow screen, a wide table may need horizontal scrolling. That can be a reasonable choice if the scrollable area is discoverable and readers can still tell which row and column they are viewing. Clear labels, sufficient spacing and a visible scroll cue can help. Check that zooming in does not hide information or make controls unusable.
Another option is to restyle each row as a compact block, with labels such as “Session,” “Location” and “Start time” beside their values. If you choose that approach, retain the underlying table relationships or provide an equally understandable alternative structure. Changing only the visual layout does not automatically make the information clearer to assistive technology. In either view, do not rely on color alone to convey status, availability or other meaning.
Test the experience, not just the appearance
Read through the table without using its visual alignment as a guide. Can you identify what each value describes? Then navigate it with a keyboard and, where possible, a screen reader. Listen for the caption and headers, check the order of cells, and try the table at a narrow width and high zoom. These checks can reveal problems that are easy to miss when a table looks tidy on a desktop screen.
If a table can be sorted, make the control operable by keyboard and communicate which column is sorted and in which direction. A button in the relevant header can provide an understandable action; the current sort state should be exposed as well as shown visually. Finally, ask whether the table helps readers complete its actual task. In the workshop schedule, someone should be able to find a session, understand where it meets and know when it begins without guessing what any cell means.
