Before you start
Like any type of content, start with user needs. Before you create a table, make sure it’s the right format for the information you’re presenting, and meets a user need.
When to use a table
Each use case will vary but you may want to think about using a table when any of the following applies:
- your user needs to quickly locate specific information from a large set of data
- your user needs to compare similar information side-by-side, eg product features
- the information can't be presented as a simple list
- the information would be repetitive if written in a paragraph
Answering the question ‘it depends’
In her book Letting Go of the Words, Ginny Reddish writes:
‘When a site visitor asks a question to which your first answer is “it depends,” that’s a clue that you need a table. What it depends on becomes the left column of the table. The answer to the question for each site visitor’s situation becomes the right column.’Ginny Redish - Letting Go of the Words
This table answers the question "Do I get free treatment for my pet" with the answer “It depends what type of insurance you have”.
Example Answering the question ‘it depends’
|Compare Pet Insurance||Classic||Select Plus|
|Vet fees cover||£2000||£5000|
|Extra treatments||Not included||£750|
Don’t assume that people will look at every row
They will usually scan down the left side of the table until they find a cell that interests them and read across, jumping up to check column headings as they read the content in that row. Most of their attention will be on the left hand column.
Even a simple table takes effort to use
Remember that many people use screen magnification and need to zoom into the content to be able to read it. Without cell borders it may be hard for a reader to realise they are in a table — if there are lots of blank cells, or if the header (question) row or left hand column is not visually different to the answer cells. There’s no context to help them understand what they’re reading.
‘Tables get slightly more complex to look at and to deal with when the user needs to refer to the top row, the left column, and a cell within the table to find an answer. It’s sort of like finding a location on a map: You have to locate the longitude, the latitude, and the point where the lines intersect.’Nielsen Norman Group
When not to use a table
If your table only has one column, use a bulleted list instead.
If most of the content is the same (for example if there is the same value in every row or every column), don’t put it in a table. Try adding a framing paragraph before the table to explain what the things you are comparing have in common, before using the table to show how they are different.
In addition to the rules about using numbers and units, there are some things to remember when creating content for a table.
Asterixis and footnotes
Try and avoid using asterixes and referring the user to footnotes outside the table as it breaks the reading flow.
We're exploring alternative patterns to footnotes and will update the design manual when we're ready to make a recommendation.
Blank cells and zeros
Avoid blank cells as they can be confusing. It’s best to try and answer the question or explain why there isn’t a value that isn’t of the same type of the rest of the cells. (An exception to this is the top left cell in a table, which can be left blank.)
A blank cell could be a sign that a table is not the right way to represent the information.
In this example, boarding fees aren’t covered in the simple plan, so a blank cell is technically correct. However, it would be easy to think that the boarding fees were free.
Answering the question is more helpful, and there’s less chance of misunderstanding.
Example Avoiding blank cells
|What’s covered||Simple plan||Extra plan|
|Boarding fees||Not covered||£1000|
Use a zero when the thing you are measuring does exist, but has a value of zero. For example:
Example Using zero
The top left cell can be completely empty, although it must be marked up as an ordinary cell (
<td>) and not a column heading (
<th>). This is to make the table is understandable to people using screen readers.
To learn more about tables and screen readers visit www.w3.org/WAI/tutorials/tables/two—headers
If you find that your table has content that is repeated in every cell in a row, consider pulling it out and presenting it before or after the table. This will reduce the size of your table and make it easier to scan.
Every table needs a heading that describes what the table is for.
This heading should appear directly above the table.
Ticks and crosses
Approach ticks and crosses with caution. They can be helpful but need the correct markup (ARIA or alternate text tags) to be understood by people using screen readers.
Consider using Yes or No, or answering the question (so that the content makes sense to someone who is using a screen magnifier).
Don’t mix different types of content like ticks and numbers within the same column.
No more that 15 words per cell, and ideally far fewer.
If your table is mostly text, consider laying it out as structured copy, as this will be easier to read and understand.
Column headings should be as brief as possible — no more than five words.
Column headings should align with the column content.
Text align left. Numbers align right (to maintain the order of magnitude). Do not centre any type of content — it is very hard to read.
Use colour when you need to make a distinction between one grouping of data from another. Examples of this are hover or selection interactions for rows or columns. When colour is used ensure there is sufficient contrast between colour and type. Make sure you’re familiar with the advice about designing for people with different access needs.
void using zebra stripes for rows as this adds emphasis to the rows with colour where none is needed.
If there are decimal points, line them up. Consider whether rounding to a larger number (example: thousands) might meet user needs better.
Use emphasis to show the reader what’s important. For example, it may or may not be appropriate to use emphasis on the row headings.
For content within the table (excluding row and column headers) use emphasis only if it supports the user need is for that table and for the page as a whole.
The heading for the table will always be within the semantic context of a wider page. This means that the size of the table heading will be defined by the established typographic hierarchy (not by the table).
Rules (horizontal and vertical lines)
Avoid using vertical rules to separate columns or as a table border; they add visual clutter.
Use horizontal rules to help the user scan rows. Use a heavier rule to separate column headers from the column content.
There’s more information about how to use rules in tables that respond to different screen sizes: Responsive tables.
Use a maximum of 3 type sizes in a table. More than this can create visual noise. Within a row, cell content should be aligned on the same top baseline, irrespective of differing amounts of content per cell.
Ideally, column and row headings are the same type size as rest of the table content.On mobile retain the emphasis used for desktop and tablet.
Vertical and horizontal space
The width of a table and its columns should be appropriate to the content. A table shouldn’t have to be as wide as the available space — if it is, it may be too large for the content.
Don’t define heights of rows — let them be the height they need to be. Use percentages to define widths of cells.