Data visualisation: tables

Introduction

This guidance provides advice on how to present and publish demonstration tables in HTML and document formats.

Demonstration tables are used to reinforce a point made in the text of a publication. They are smaller and less detailed than reference tables.

Reference tables are used to supply data in a way that can be reused. They are usually published in a spreadsheet format. Advice on creating and publishing reference tables is in our ‘Releasing statistics in spreadsheets’ guidance.

Accessibility legislation

Accessibility legislation came into force in September 2020. This means all content published on public sector websites must meet the level A and AA success criteria in the Web Content Accessibility Guidelines 2.2.

Consequences for inaccessible content

Content on public sector websites that does not meet the Web Content Accessibility Guidelines 2.2 can get complaints related to the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 and/or the Equality Act 2010. This could cause reputational damage and loss of public trust.

Make sure whoever is responsible for the content you publish is aware of this and the possible risks involved.

Using tables in publications

Demonstration tables are useful when:

• you want users to compare values
• you want to include values and measures such as percentages or indices
• you want to include summary statistics such as averages or totals
• you need to show values of very different sizes in the same display, for example values in the tens and values in the millions

Charts should be used when you want to show patterns, trends and relationships.

Reference tables should be used when you want to supply large amounts of data for further analysis.

Layout

Comparing numbers

To help the reader make comparisons:

• present the numbers close together
• present the numbers in columns, not rows
• use the same level of precision within each column
• use commas to separate thousands
• right align the figures and the column headings
• start numbers of less than one with a zero, not a point

Example: Figure 1.1 (fictional data)

People employed at each Civil Service grade, UK, 2018

This table shows values and percentages. The data are presented in columns, not rows. The data columns are right aligned and the same level of precision is used within each column (for example the percentages are all to one decimal place). This ensures units sit above units, tens above tens, hundreds above hundreds and so on. Commas are used to separate thousands and numbers of less than one start with a zero, making the data easier to read.

An improvement in this table would be to make the column showing the percentages a bit narrower. But when publishing tables in HTML we are sometimes restricted in what we can do with the layout. If we were publishing this table in a text document that is an extra edit we would suggest making.

Rounding

Presenting too much detail can make things harder for users. Rounding numbers makes them easier to read and remember.

For example, in Figure 1.1, headcount numbers are rounded to the nearest ten.

The extent of rounding will depend on the intended use. A journalist may be happy to report that the population of the UK is 66 million, or that the population has changed from 64.1 million to 66.4 million. An analyst performing further calculations will want to work with more precise figures.

Rounding does reduce precision. This usually means that the reported totals no longer equal the sum of the component parts.

Making a decision on rounding can be difficult when the values show a variety of units. Consider rounding to a fixed number of significant figures or effective digits.

Grouping

Objects grouped together are assumed to be associated. White space and can be used to separate data into groups.

The best way to provide white space is to adjust column width and row height. Do not use blank rows or columns as this can make things confusing for screen reader users.

Example: Figure 1.2 (fictional data)

People employed at each Civil Service grade, UK, 2018

This table shows the same data as in Figure 1.1, but in this presentation we have used line breaks in the HTML code to create white space that puts administrative roles, executive roles, Grade 6 and 7 roles and Senior Civil Service roles into four groups.

Indentation

Indentation is sometimes used in tables to indicate hierarchy, for example, to indicate a list of regions under a row for ‘England’. It is generally OK to use indentation in demonstration tables. But, be aware that in spreadsheets, indentation can cause problems for machine readability. See our guidance on ‘Releasing statistics in spreadsheets’ for more information.

Ordering categories

Ordering the categories in a table can make it easier for users to see patterns and groups in the data.

For some categorical variables, like month of the year or age group, there is a natural order for presentation. Other variables may have harmonised ordering, such as regions of the UK.

Use natural or harmonised principles whenever possible. An appropriate order may also be obvious from knowledge of the subject matter. For example in Figure 1.1 in this guidance we order Civil Service grades by seniority, it would not make sense to order them alphabetically.

Ranking categories

If appropriate, consider ordering your categories according to the statistics in one of the columns. For example, place the largest value at the top. This shows the rankings of the categories on that statistic.

Ranking the categories in this way emphasises the relative positions of the categories. It may also show where some statistics differ from the overall pattern. Be aware that in some cases, the relative positions may be determined by random variation.

Summary rows and columns

Summary rows and columns, for example for totals, are traditionally placed at the bottom or right of the table. If it’s important for users to see totals first, it may be helpful to place the totals at the top or left.

It can be useful to use bold text to draw attention to summary rows and columns. But be careful not to overuse bold text.

Example: Figure 1.3 (fictional data)

People employed at each Civil Service grade, UK, 2018

This table shows the same data and presentation as in Figure 1.2, with an extra row showing the total headcount.

Titles

All tables should have a title.

Ideally, they should have a headline title which states the message you’re trying to get across and a statistical subtitle stating what the data is and the geography and time period it relates to.

You do not have to have a headline title, but we recommend them as they help users see the messages in the data.

If you have a mix of charts and tables in your publication, it may be useful to use ‘Figure n’ in the titles instead of numbering tables and charts separately.

Column headers, row labels and merged cells

Column headings and row labels are important parts of tables. Column headings should describe the data in each column. Units should also be described, unless all the data in the table has the same units. In this case information on units can be given in the table title.

It is also very important that tables published in HTML have properly ‘marked-up’ column headers and row labels. This mark-up allows screen reader software to understand the table layout.

This mark-up also allows HTML tables to have merged cells in the table layout.

But note: merged cells in tables published in spreadsheets and text documents are not accessible. This is because the document software does not yet have the more complex mark-up this type of layout needs. Also, be aware that some HTML table builder tools may not allow you to use merged cells.

The ‘Publication’ section of this guidance has more information on what table mark-up is and how to do it.

Footnotes

Tables can have footnotes but they should be avoided whenever possible as jumping from one section of text to another can be confusing. It is better to put the information at the point of need.

If you do have to use footnotes, it is best practice to place them in the title, column headings or row labels. Avoid placing them in cells with data, this affects the alignment of the figures and can make the table more difficult to understand.

Source

It is best practice to give the source of the data in the table and hyperlink to it. This information should go underneath the table.

Source information should be provided in the following format: [publication, survey or other source of data] from the [organisation].

For example: Source: Childcare and early years survey of parents from the Department for Education.

If the table uses more than one source you should list them all.

If all the tables and charts in your publication have the same source, you can state this somewhere else in the publication. You do not need to repeat the source information under every figure.

Fonts

Generally if you publish your table in HTML you will not have much control over the fonts used. But, if your publication is in a text document you will.

Tips for fonts:

• Stick to one type of font.
• Use font size 12 point or bigger.
• Avoid superscript (see our guidance on releasing statistics in spreadsheets for advice on how to refer to notes).
• Use a sans serif font, for example Open Sans, Arial or Tahoma (serif fonts like Times New Roman can be more difficult for some people to read).
• Bold font can be used for emphasis but do not overuse it.
• Do not use italic text as it can be hard to read.

Shading

Shading should be avoided in tables whenever possible.

If you need to use shading you must not use it as the only way to communicate a message. Using colour like this will fail accessibility success criterion 1.4.1 use of colour.

You must also ensure the colour contrast ratio between the shaded background and the font colour is 3 to 1 or higher. More information on the use of colour is in our colours guidance. 

Gridlines

Do not over use gridlines. They can help a user read data from a table, but if they are too dark or there are too many of them they can make a table hard to read.

If you publish in HTML you may not have much control over the gridlines shown on a table. If you publish your table in a text document you will.

Generally, it is a good idea to mark out the line under the header row and the lines above and below any summary statistics.

Symbols and shorthand

Our guidance on using symbols and shorthand provides specific advice on this topic.

Advice from Government Digital Service

The content design manual from Government Digital Service contains advice about the layout of tables published on GOV.UK.

Publication

Using HTML

We advise that all publications on public sector websites should be in HTML. Demonstration tables within these publications should be built into the HTML code of the webpage. Images of tables should never be used as they fail accessibility success criterion 1.4.5 images of text.

When tables are published in HTML they need to be ‘marked-up’. This means using HTML code that presents the data as a table. This code tells screen reader software there is a table, how many columns and rows it has, where the edge of the table is and how the row labels, column headers and data cells are laid out.

Improving your understanding of how screen readers deal with HTML tables and watching this video of a screen reader accessing a table may help you understand how tables are marked-up in HTML.

How to create ‘marked-up’ tables

How to correctly mark-up your table in HTML depends on the website you are publishing on. The Government Digital Service have provided guidance for publishing tables on GOV.UK.  The websites for Office for National Statistics (ONS) and Explore Education Statistics have specific table builders.

If you need to, you can convert a table created in Word or Excel to a table in ‘Markdown‘ (the language needed to publish in HTML). You can use an online markdown conversion tool to do this, but be careful about using it with unpublished data.

W3C also provide a tutorial on producing tables in HTML, including information on how to mark-up a table layout that includes merged cells in the header row.

If you’re unsure about how to publish tables on your website ask someone in your department, try your presentation champion.

Examples of tables in HTML

Examples of the tables you can create in HTML on GOV.UK.

Table 1 in this release on sexual orientation from the Office for National Statistics

Using an accessible document format

If you are publishing your table in a document format it will need to be made accessible.

Advice on publishing accessible tables in an Open Document Spreadsheet or Excel format can be found in our ‘Releasing statistics in spreadsheets’ guidance.

When making tables in Microsoft Word you should use the ‘insert table’ tool.

You should also make sure:

• the table has a defined header row (highlight the header row – click the blue ‘Table Design’ tab and then click the ‘Header row’ checkbox on the top left)
• the checkbox that says ‘Repeat as header row’ is checked in table properties if your table runs across multiple pages – this means the header row is repeated at the start of the table on each page the table runs onto, so users do not have to keep referring back up to the top of the table
• the checkbox that says ‘Allow row to break across pages’ is not checked – this stops table rows splitting across more than one page
• to check the reading order of the table is sensible by tabbing through the table content

You can also add alternative text in the table properties, but this is not strictly necessary for tables.

Note: these instructions will depend on which version of Microsoft Word you have.

Example

Estimated and projected population of the UK and constituent countries (DOC, 16KB)

Note: we would normally advise to use an Open Document Text file for text documents. But, we have found that saving a text document with tables in an ODT format removes the table mark-up, so we advise to use a Microsoft Word document format for now.

Using an accessible PDF format

If you are publishing your whole release in a PDF format then you can include a table in your PDF but it must be marked- up correctly to pass accessibility regulations. More information on how to tag tables in PDF documents.

If you are publishing your whole release in an accessible HTML format and providing an accompanying PDF version, the PDF version does not need to pass the accessibility regulations, but it is best practice to make sure it does.

Publishing reference tables

Reference tables usually contain lots of data and are aimed at users who need detailed data.

They are are best supplied in an accessible spreadsheet document. Please see our guidance on ‘Releasing statistics in spreadsheets’ for more detailed information on how to create accessible spreadsheets.

Related links

Guidance from the Analysis Function Central Team:

• Charts: a checklist
• Data visualisation e-learning
• Data visualisation: colours
• Using our colour palettes in Microsoft, R and Python
• Data visualisation: charts
• Data visualisation: infographics
• Releasing statistics in spreadsheets 
• Resources to use with our releasing statistics in spreadsheets guidance
• Using symbols and shorthand 
• Making analytical publications accessible
• Dashboards

Other links

• Analysis Function YouTube channel 
• Tables section of the content design manual from Government Digital Service
• How to publish accessible tables on GOV.UK 
• Advice on tables from the Office for National Statistics style guide

Any questions?

If you have any further questions you can:

• email Analysis.Function@ons.gov.uk
• join our Basecamp project for accessibility for statistics and analysis or presentation and dissemination of statistics and analysis – if you are not on the Cross Government Basecamp, email Analysis.Function@ons.gov.uk for an invite link
• contact your departmental presentation or web dissemination champion
• contact us through Twitter @gov_analysis