Using tables in documents is a great way to help readers understand content quickly and easily. You can use them to provide or compare data, to present complex information more simply, or to help abbreviate an overabundance of body copy.
A good table should be like the shelves in a well-run bookshop – the contents are easy to scan and organised logically. A bad table is like the book section at an op shop – usually disorganised, illogical and possibly a turn-off.
So to help you create beautiful bookshop-quality tables every time, we’ve put together some tips.
Table basics
Before you begin, make sure a table is the best tool for you. Ask yourself whether the information would be better suited to a graphic (for example, if you want to compare data points, perhaps a bar chart would provide greater clarity and have more impact). Or it might work better in a list or as prose, especially if you have only one or two data points.
If you decide to go with a table, essential elements that will make it ‘talk’ to your reader include:
- a caption and a number (unless there’s only one table)
- column headings across the top
- row headings down the left‑hand column.
It’s also important to make sure it’s accessible for screen readers, devices that read out text to people with visual impairment.
Captions and numbering
Write clear captions that describe what the table is showing – for example, ‘Table 1: Monthly rainfall recorded at the Sydney Botanic Gardens 2012–22 (mm)’. Try to keep the caption to a single line.
Number the tables in a document and refer to them in the body text (called ‘in-text references’), so readers can find them easily and will know exactly what text they relate to. If you have to renumber them because you’ve inserted or deleted one or more, remember to update the in-text references too.
Column and row headings
Writing the headings
Tables are created using vertical columns and horizontal rows. Always give the rows and columns headings. Keep them short and simple, stating the type of information each column and row contains.
If you’re including units of measurement, put the symbol in brackets in the heading only – for example, for millimetres, you would insert ‘(mm)’. Don’t put the unit beside each entry. The exception to this rule is if the rows show different types of data – for example, ‘mm’ and ‘%’. Then you must insert the symbol in each row heading.
If you have more than one table, use the same font, font size and colour for a consistent look. If you’re using solid colour in the row headings – say, white on blue – use it for each table in the document.
Formatting and alignment
Align row headings on the left in the first column. That’s the easy part. How you align the column headings and table text can partly depend on personal taste. But as a rule of thumb, if you want to centre the text or numbers in the cells, then centre the column heading too.
Here are a few more loose ‘rules’ for columns, depending on whether you’re dealing with text or numbers and whether or not the numbers have to add up:
- A few words of text – centre or left-align the text and headings.
- Sentences – left-align the text and headings to make it look neater.
- Numbers with a total – right-align the heading and numbers, or centre everything. But if you go for centring, make sure the last digits align on the right, being especially careful if you have decimal places (which should be a consistent number).
- Numbers that don’t have to add up – centre or right-align them.
In longer tables, use lines between rows and/or alternating tinted rows to make it easier for the eye to follow the data.
Finally, don’t leave too much white space between columns because it can be hard for the eye to track across a row, and it looks a bit odd.
We created Table 1 to show best practice (note, this is an in-text reference). It includes all the elements mentioned.
Table 1: Monthly rainfall recorded at the Sydney Botanic Gardens 2012–22 (mm)
Year | Jan (mm) | Feb (mm) | Mar (mm) | Apr (mm) | May (mm) | Jun (mm) | Jul (mm) | Aug (mm) | Sep (mm) | Oct (mm) | Nov (mm) | Dec (mm) |
2012 | 195.2 | n/a* | 271.5 | 189.2 | 53.3 | 267.8 | 65.9 | 23.7 | 25.2 | 31.4 | 53.4 | 47.1 |
2013 | 186.0 | 188.2 | 65.7 | 232.3 | 111.0 | 358.6 | 38.8 | 17.0 | 56.2 | 38.0 | 197.9 | 37.9 |
2014 | 20.4 | 62.8 | 128.6 | n/a | 39.0 | 68.6 | 18.9 | 214.2 | 54.8 | 94.2 | 23.7 | 139.7 |
2015 | 200.6 | 57.7 | n/a | 406.1 | 102.5 | 126.3 | 49.0 | 94.0 | 94.1 | 53.1 | 127.9 | 116.8 |
2016 | 268.2 | 34.2 | 220.8 | 121.1 | 7.9 | 374.8 | 101.8 | 160.9 | 77.8 | 32.1 | 30.2 | 65.5 |
2017 | 55.6 | 236.0 | 340.1 | 84.8 | 34.3 | 207.2 | 14.8 | 26.4 | 0.6 | 61.0 | 71.8 | 54.0 |
2018 | 44.8 | 102.4 | 121.6 | 26.3 | 26.4 | 206.8 | 13.1 | 15.1 | 55.3 | 156.2 | 175.6 | 102.7 |
2019 | 54.7 | 85.4 | 248.7 | 8.2 | 15.4 | 183.3 | 49.3 | 92.1 | 114.2 | 35.6 | 27.0 | 1.9 |
2020 | 64.4 | 468.2 | 179.1 | 34.8 | 144.9 | 80.4 | 180.5 | 67.0 | 34.2 | 97.9 | 69.6 | 123.5 |
2021 | 100.5 | 124.1 | 457.2 | 14.8 | 64.3 | 87.6 | 39.6 | 87.8 | 54.8 | 60.8 | 138.7 | 163.3 |
2022 | 155.8 | 364.4 | n/a | 269.1 | 233.5 | 22.5 | n/a | 69.4 | 110.3 | 263.7 | 60.0 | 71.2 |
Source: Australian Government, Bureau of Meteorology, monthly rainfall.
* n/a means ‘not available’.
The contents
When creating a table, you can do a few things to ensure you’re following best practice.
Justify using a table
Make sure you have three or more data points or pieces of information. Anything less and you should include the information in the body text instead.
Stick to the essential information
Don’t pack it with so much information that it’s hard to read or confusing. And if you do have to include a fair bit, be kind to your reader by not making the font size so small that it’s hard to read or scan easily.
Use notes
When you need to clarify or expand on information, or include a source or definition, insert a symbol next to the point and the symbol and text directly beneath the table.
Use in-text references
Refer to each table in the body text, using the table number – for example, ‘(see Table 1)’. Don’t write ‘(see table below)’ just in case it ends up on the next page in a printed document or isn’t below on a mobile device. Citing the table number also helps if you need to refer to it more than once, especially if other references are in a different or distant section of the document.
It’s also important to insert a table near or straight after the main in-text reference. This saves your reader from searching for it and means they may find it easier to understand your point.
Be consistent
If the text and table provide conflicting information, you’ll lose your credibility. So check that the information matches and fix any errors.
Don’t make it too long
When it comes to tables, bigger isn’t always better. If it’s really long and complicated, consider breaking it up into separate, smaller tables on individual topics.
If you’re working on a print document, try to keep the table to one page. If it spills onto the next page, either repeat the column headings or repeat the caption and add ‘continued’ or ‘cont.’
Similarly, if you have several tables running one after another, lay them out as separate tables with their own captions and headings. Don’t just use blank lines to show where one table ends and another begins. Doing so will confuse screen readers.
Fill in each cell
If you need to leave any table cells blank because you don’t have information to insert, don’t leave them empty. Insert an en dash (or a hyphen if you prefer, although we don’t recommend this), ‘n/a’ or other text, as appropriate. If you’re working with numerals, only insert ‘0’ if that’s the true value. Otherwise use an en dash or ‘n/a’.
Keep accessibility in mind
Make your tables accessible for people using screen readers. Here are some ground rules:
- Write alternative text (usually referred to as ‘alt text’) summarising the information in the table. This allows the person to decide whether they want to hear the whole table. Where you insert the alt text will depend on the program you’re working in, so you may have to do some research.
- Avoid nested tables (tables within tables) because screen readers can’t make sense of them.
- For the same reason, don’t merge or split cells.
- Give each piece of data its own cell.
For more detailed guidance and explanations, visit the World Wide Web Consortium’s tips and tricks for making accessible tables.
If you would like help creating content, feel free to get in touch.
By Kim Irving