Three Tips for Tables People Can Actually Use
Tables are powerful when they hold real data, and a problem when they are used for anything else. These three habits keep them readable.
The basics come down to this:
- Keep each table simple
- Mark up row and column headers
- Use tables for data, never for layout
Keep Tables Simple
A screen reader reads a table cell by cell, announcing where it is as it goes.
Merged cells and tables sitting inside other tables break that running commentary, so the listener loses track of which row and column they are in and gives up. The fix is almost always to simplify, not to pile on more markup. Aim for one table per topic and one piece of information per cell, and split anything complicated into two simpler tables.
Some examples:
- A timetable that crams “Room 3, Dr Lynch, 9am” into one cell mixes three facts in a single space. Split it into three columns for time, room and lecturer. Each cell then holds one piece of data, which a screen reader can read back cleanly.
- Merging cells to create a sub-heading row inside a table breaks the grid a screen reader expects. The reading order goes astray and the listener loses their place. Make a second, separate table with its own caption instead.
- A header that spans and merges across several columns is hard to follow cell by cell. The association between header and data turns ambiguous. Give each column its own plain header so every value has a clear label.
To go further on this, two references:
Mark Up Row and Column Headers
Header cells tell a screen reader which heading belongs to which piece of data.
This is what lets the tool say “Maths, term two, 73” instead of just “73.” Without headers the table is a field of loose numbers with no labels attached, and a screen reader user has to count rows and columns in their head to work out what each one means. Set the top row and the first column as headers with the right scope, and give every table a caption that names it.
Here is what that looks like in practice:
- In a results table, set the subject names along the top row as column headers and the student names down the side as row headers. With the scope set correctly, any cell now reads back with its labels attached. A learner lands on a figure and hears “Maths, term two, 73.”
- A caption such as “Term 2 results by subject” names the table as a whole. Screen reader users browsing in table mode use it to tell one table from another. Without it, they enter a grid of numbers with no idea what it represents.
- In a budget table with only the numbers marked up, a screen reader user hears “1,200” and cannot tell whether it is the rent, the total or the shortfall. The figure has lost its label. Proper headers reattach the meaning to every number.
Two resources worth a read:
Use Tables for Data Only
A table is a promise that the content is tabular, and assistive tech reads it that way.
Use one for layout and you force a confusing cell-by-cell read on something that was never a grid. Use an image of a table and it is worse again, because a picture has no structure a screen reader can use, and none of the text inside it can be selected, searched or resized. If you have data, build a real table; if you are arranging a page, use layout styling.
What that looks like day to day:
- A spreadsheet screenshot pasted in as a picture has no structure a screen reader can use. None of the figures can be selected, searched or resized either. Rebuild it as a real table and all of that comes back.
- Using a table just to sit two blocks of text side by side forces a cell-by-cell read on something that was never tabular. The reading order can come out jumbled. Use headings or layout styling for the arrangement, and keep tables for data.
- A “pros and cons” set laid out as a two-column table only for the look is being used as a layout device. Either make it a genuine data table with proper headers, or present it as two headed lists. Both options keep the meaning intact for assistive tech.
Two places to dig deeper:
