Releasing statistics in spreadsheets

Who is this guidance for and what is its aim?

This guidance has been created for producers of statistics who need to publish data tables in spreadsheet documents.

Its aim is to help improve the usability, accessibility and machine readability of statistical spreadsheets.

The guidance is detailed but much of it will only need to be implemented once.

If you are not publishing statistics but still using spreadsheets you might want to look at the more general guidance on creating and sharing spreadsheets published by the Government Digital Service (GDS).

Accessibility, usability and machine readability

Accessibility

Digital accessibility is about making online content easy to access, understand and use.

Spreadsheets published online by the public sector must meet the AA level of the Web Content Accessibility Guidelines (WCAG) 2.2. This is a legal requirement set out in The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.

Some of the WCAG 2.2 are generic in nature. Throughout this guidance, using our knowledge, research and interpretation of WCAG 2.2, we have tried to make a clear distinction between things we feel must be done in order to meet the legal accessibility regulations and things that are considered accessibility best practice.

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.

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

Usability

Some of our advice is based on best practice for improving the usability of spreadsheets. This often overlaps with our advice for accessibility. We outline when a piece of advice relates to usability but is not covered by the legal accessibility regulations.

Machine readability

Some sections mention best practice for machine readability. Often this overlaps with our advice for accessibility and usability. Sometimes it contradicts it. Depending on the complexity of your spreadsheets and your user needs you may wish to publish two separate products. One for users who wish to download, read and analyse your spreadsheet and one for users who need your data to be optimised for machine readability.

We outline when the advice relates to machine readability and when there are possible clashes with the accessibility advice.

Engage with users before making changes

Before making any big changes to your spreadsheets you should consult with your users, to warn them and to find out more about their needs.

Some questions you might want to ask:

• What are the statistics used for?
• What questions do they answer?
• What problem is this solving?
• How do users access and view the statistics?
• What questions do users ask about the statistics?
• What tools do your users use?
• Are the statistics re-used in other analysis and outputs?
• Do your statistics meet the needs of your users?
• Do your users have new requirements or suggestions about how to present the statistics differently?
• Are all of your statistics still needed and used?
• What additional information is needed to support your users in their use and re-use of the statistics?
• Are your statistics presented in ways which are simple and convenient for your users?

Tables

In statistics we generally deal with two types of tables – demonstration tables and reference tables.

If we are using a table to demonstrate a point we are making in the text, we create a demonstration table. These lay out statistics to quickly reinforce a point.

Generally these should be published within publications and not as attachments or downloads. They should be published within the code of the publication, ideally in HTML on a webpage or as part of a text document.

You should not publish images of tables as these are likely to fail accessibility success criterion 1.4.5 images of text.

You can find out more about best practice for demonstration tables in our ‘Data visualisation: tables’ guidance, our ‘Making analytical publications accessible’ guidance and ‘‘Module 11: tables’ in our data visualisation e-learning.

This guidance focuses on reference tables.

Reference tables usually have lots of rows and columns and are aimed at users who want detailed data. There may be a wide variety of statistics broken down into different categories. They are generally supplied in a spreadsheet document.

Marking up tables in spreadsheets

Ensure all tables in your spreadsheet are ‘marked up’ as a table – this is key to meeting accessibility success criterion 1.3.1 info and relationships, guideline 2.4 navigable and success criterion 2.4.3 focus order.

Marking up an element of a document or webpage (such as a table, heading, sub-heading or image) means code is added in the background to help software like screen readers better understand the content.

Benefits of marking up a table:

• The header row and table edges can be identified by assistive technology
• The table can be named and will appear in the ‘Go to’ tool which is a keyboard shortcut that aids navigation (see the ‘Naming tables’ section for more information)
• A user will be able to tab through the data in a sensible way. For example when a user tabs to the end of the row, the next tab will take them to the start of the row below.
  • Note: if you keep tabbing past the end of the last row it does lead to extra rows being added to the table. However, as the table is marked up correctly, users of assistive technology should know when they get to the end of a table, so this is not considered an issue.

How to mark up a table in Excel:

Be aware these instructions may differ slightly for different versions of Excel.

These instructions outline the manual process. There is a way to automate this process now using coding skills. More information on how to automate creating accessible spreadsheets.

1. Select the cells you want to include in the table.
2. On the ‘Insert’ ribbon, select ‘Table’.
3. In the ‘Create table’ dialog box, check the ‘My table has headers’ box
4. Select ‘OK’.

Excel will, by default, give you a table with alternating blue colours. It will also make every column a filter. This is not great for accessibility.

Make the Excel default table accessible:

1. Click somewhere in the table
2. Click the ‘Table Design’ ribbon.
3. Select a plain table format in the ‘table styles’ section – go right to the top and you’ll see the plainest option with no formatting (you can make this the default table format by right clicking on it and selecting ‘Set As Default’).
4. Uncheck the ‘Filter Button’ box in the ‘Table Style Options’ section.
5. If you have row labels in the first column, the cell in the header row will automatically be labelled ‘Column 1’. You need to replace this with something sensible, it cannot be left blank.

Other pointers for table formatting

It is best practice to:

• highlight column headings and row labels by setting the text to bold
• ensure the ‘default’ or ‘automatic’ colour is selected for all text (see the section on ‘Formatting and use of colour’ for more information on why this is important)
• left align all text in cells outside the table and all row labels within the table
• right align all data within a table and all column headings (except ones above row labels or other text columns – these should be left aligned)
• the default table will make the columns as wide as the text in the header row, it is better to make the columns narrower – very wide columns make it difficult to compare numbers and cause issues with navigation

Example of a table with accessible formatting (ODS, 5.73KB)

Note: right aligning figures is important as it ensures the numbers are displayed in a way which makes comparisons easier. For example, it ensures all the thousands, hundreds, tens, and units are on top of each other. This is particularly important when you have negative numbers.

Adding headers to a table that is already marked up

If the table is already created and you want to tag the header row:

1. Place the cursor anywhere in the table.
2. Click onto the ‘Table Design’ ribbon.
3. Check the ‘Header Row’ box.

Naming tables

Make sure all tables in your spreadsheets have meaningful names. This will aid navigation for everyone. It will also help you pass accessibility success criterion 2.4.6 headings and labels and guideline 2.4 navigable.

Name a table in Excel

1. Click anywhere in a marked up table
2. Click the ‘Table Design’ ribbon
3. In the ‘Properties’ section there is a box to edit the table name
4. Type the table name in – note that words must be split up with underscores

Check navigation with named tables

If you want to see a list of all the tables in your worksheet go to the ‘Formulas’ ribbon and click ‘Name manager’.

To test out navigation you can press ‘Ctrl + G’. This brings up a ‘Go to’ tool. All marked up tables will be listed here. You can click onto one of your tables and select ‘OK’ to be taken directly to that table.

Merged and split cells and nested tables

Restructure your tables so there are no split cells, merged cells or nested tables. This is a crucial issue to address as it is key for both machine readability and accessibility.

Merged cells, split cells and nested tables make table structure hard to understand for assistive technology like screen reader software. Removing these elements is key to meeting accessibility success criterion 1.3.1 info and relationships.

Example of a table with unmerged cells and one header row (ODT, 6KB)

Blank rows and columns within tables

Remove all blank rows and blank columns within tables. These may be perceived as the edge of the data area rather than a divider and so they could lead you to fail success criterion 1.3.1 info and relationships.

If your table is marked up correctly, blank rows and columns may not be as much of an issue, but they can still be confusing so it is best practice to remove them.

If blank rows and columns are used to create white space to illustrate certain groupings, you can do this by adjusting column width and row height instead.

Column headings

Every table in your spreadsheet must have a correctly tagged header row, as described in the ‘Marking up tables in spreadsheets‘ section. This is key to passing accessibility success criterion 1.3.1 info and relationships.

Things to note:

• Excel can only tag one row as the header row.

It is not necessarily a fail of the accessibility guidelines if you have subheading rows, but as they cannot be tagged as headers it may make the table confusing – so whenever possible, it is best avoided. Sticking to one header row is also good for machine readability as some programming languages cannot interpret subheading rows.

However, if you have codes in your table such as area codes or dataset identifiers it is better to put these in a subheader row or column. Look at the example spreadsheet on the accompanying resources page for this guidance to see how this is done on there.

• All columns must have text in the header row or Excel will give it a default name when you mark up the table.
• Header names must be unique – a table can’t have two columns with the same text in the header row.
• You can space out information in the header row by pressing ‘Alt’ and ‘Enter’ at the same time to create a line break. This is particularly useful when displaying information about units or notes.

Example of a table with unmerged cells and one header row (ODT, 6KB)

Consistency in column headings

Consistency is important when it comes to column headings. Clear and consistent headings help accessibility, usability and machine readability. We advise you to follow a consistent naming convention within your spreadsheets and across your publications.

If your spreadsheet uses multiple worksheets and several data tables that hold similar or identical data, use the same column names. For example: in a spreadsheet listing employee satisfaction survey results, use ‘department name’ in all data tables, rather than ‘department name’ in some and ‘name of department’ in others. This makes it easier to cross reference and understand your tables and how they relate to one another. It also helps with machine readability and further analysis.

Units

Displaying units in a consistent way is important for usability and machine readability.

Ensure it is clearly indicated if your columns use different units. If needed, put the units for your data in rounded brackets after the column heading – for example: ‘Number of people in employment (thousands)’.

It is best to space the information about units so it appears under the column heading text – you can do this by pressing ‘Alt’ and ‘Enter’ at the same time when typing in a cell.

It is good to be consistent with your use of brackets, we suggest rounded brackets for units and square brackets for notes (more on this in the ‘Symbols, footnotes and codes’ section).

Wrap text

It is important to ensure all the text within table cells is visible and clearly spaced out. This will help you to pass accessibility guideline 1.4 distinguishable. You can do this by using the wrap text function and adjusting row height and column width.

Wrapping text is important because a screen reader will repeatedly read out ‘overflowing’ or ‘cropped’ after every cell which contains text that does not fit. This causes ‘auditory clutter’ and can make tables difficult to understand.

Adjusting row height and column width is important because users with dyslexia can find it difficult to read crowded text.

It is OK if there are a few sentences outside a table that overflow their cells – a screen reader will still read out ‘overflowing’ or ‘cropped’ but as this will not be repetitive it is not a problem.

Comparing numbers

If you are inviting users to compare numbers, it is best practice to:

• present the numbers close together, in columns – this makes it easier to make comparisons and determine patterns
• use the same level of precision in each column
• use commas to separate thousands (for example ‘32,401’ not ‘32401’ or ’32 401′)
• right align the figures and the column headings
• start numbers of less than one with a zero, not a decimal point

Rounding

Presenting too much detail can make things harder for users. Simplifying numbers by rounding makes numbers easier to read and remember. This improves usability.

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. Think about what your users may need. Consider leaving the underlying figures unrounded. A screen reader user will be able to access both the rounded figure and the unrounded one.

Rounding does reduce precision. This usually means that the reported totals no longer equal the sum of the component parts. If this is the case it should be communicated clearly.

When rounding you should ensure all figures in a category are rounded to the same level of precision (for example one decimal point) and that any numbers less than one start with a zero, not a decimal point (for example, 0.56 not .56).

Grouping

Objects grouped together are assumed to be associated. When used appropriately grouping may help users understand the data better.

White space can be used to separate the data into groups. You can do this by adjusting column width and row height. Do not use blank rows or columns as this may fail accessibility success criterion 1.3.1 info and relationships.

Example of using white space to split data into groups (ODS, 5KB)

Ordering categories

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

For some categorical variables, such as months of the year, there is a natural order for presentation. Or, an appropriate order may be obvious from knowledge of the subject matter.

Other variables may have specific harmonised ordering, such as areas of the UK. More information on how to order UK areas can be found on the Open Geography Portal under ‘Guide to presenting statistics – general principles‘.

We have also published several harmonisation standards which may help you when ordering categories.

Alternatively, consider ordering categories according to the statistics in one of the columns, for example put 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. Also be aware that ordering categories in this way may be controversial and you should carefully consider the message that is being communicated.

Summary rows and columns

Summary rows and columns, for example for totals, should always be at the edge of a table. Traditionally they are placed at the bottom or right. If it’s important for users to see the summaries first, it may be helpful to place the them at the top or left.

Adding filters

We advise you to avoid adding filters. They may fail the accessibility guidelines if they obscure data.

If you do need to use filters it is important to provide signposts or comments to indicate which cells contain the drop-down menus and if any data is hidden.

You should also give details of how to turn the filters off. For example: ‘Filters are active in cell C3 and may hide some data. To turn off all filters select the ‘Data’ ribbon then ‘Filters’ button or use [Ctrl, Shift, L]’. It is important to include the keyboard commands as some users will not use a mouse.

This information should be in a cell in column A, above the table so users come across it before getting to the table.

Adding freeze panes

We advise you to avoid adding freeze panes as they may fail accessibility guideline 2.4 navigable. This is because they make it difficult for screen reader users to find the top left edge of a worksheet and they limit how much space a user has to navigate (this is particularly important for users who are using an increased zoom level).

If you do leave freeze panes active it is best practice to inform users and give instructions on how to turn them off. For example: ‘Freeze panes are turned on. To turn off freeze panes select the ‘View’ ribbon then ‘Freeze Panes’ then ‘Unfreeze Panes’ or use [Alt W, F]’.

As with filters, it is important to give the keyboard commands and this information should be in a cell in column A, above the table so users come across it before getting to the table.

Be aware that if you save your spreadsheet in the Open Document Spreadsheet (ODS) format (which we advise you to do) freeze panes will disappear.

Also note, if a table is ‘marked up’ correctly the column headings will automatically replace the column letters when you scroll down the table (as long as you select a cell within the table). This acts a bit like freeze panes.

Adding alt text to tables

Newer versions of Excel have a built-in accessibility checker which may bring up tables without alt text as a fail.

However, tables that are marked up correctly do not need alt text to pass the accessibility guidelines. It is much more important to mark your tables up correctly than to add alt text to them.

Be aware that if you do add alt text and then you save your spreadsheet in the ODS format (which we advise you to do) your alt text will disappear – but this does not matter as it is not needed to pass the accessibility guidelines.

Note: it is necessary to provide alternative text for images and charts and this does not disappear when you save in the ODS format.

Cells with no data

Accessibility and usability for cells with no data

If you leave cells with no data blank, it can cause confusion for users of assistive technology because it makes it difficult to work out where a table starts and ends. Therefore, blank cells could be considered a fail of accessibility success criterion 1.3.1 info and relationships and guideline 2.4 navigable.

Furthermore, in terms of usability, blank cells in a table may be considered bad practice as they do not tell a user why there is no data in the cell. A user might incorrectly assume the data value is zero or that there has been a mistake and data is missing.

However, if the following points are met, blank cells should not cause usability or accessibility issues:

1. There is only one reason a cell in a table may be left blank
2. The table is marked up correctly (as described in the tables section of this guidance)
3. There is a note above the table, in a cell in column A, explaining that some cells are left blank and why

See worksheet 4 on the example spreadsheet on the accompanying resources page for this guidance for an illustration of this.

More than one reason for a blank cell

If there are several reasons a cell in a table may be left blank you will need to use shorthand to explain why a particular cell has no data.

Do not use symbols like full stops (..) or dashes (-). Instead, you should follow our guidance for Using symbols and shorthand in tables. Using this guidance ensures cells with no data are marked up in a consistent way across government.

We advise the use of square brackets for all shorthand used in a table because it makes it easier to spot. We also advise it because we advise round brackets for descriptions of units – consistency in the type of brackets used is important.

When using shorthand you should mention it is used and explain what it means, in a cell in column A, above the table. If you wish to expand further on why some cells have no data you can say the full explanation is available on the cover sheet or in the notes table. More information on the cover sheet and notes table can be found in the Structure section and the Metadata worksheets section.

More information on the use of symbols and shorthand can be found in the Symbols, footnotes and codes section.

Example of cells with no data marked up with shorthand (ODS, 3.96KB)

No to NA

We do not advise using ‘NA’ to describe cells with no data. This shorthand is ambiguous, some may read it as Not Applicable, others may read it as Not Available.

Give a heads up on the cover sheet

If your spreadsheet contains cells with no data for many different reasons – for example some are empty because the data was missing, some because the variable was not applicable – it is good practice for accessibility and machine readability to outline the possible reasons for empty cells on the cover sheet. You can say something like ‘Some tables in this spreadsheet have cells with no data. When this is the case the cells are marked up with shorthand: [x] for not available, [c] for confidential and [z] for not applicable’. This means users know what to expect and programmers are better able to write code that matches what is in your tables.

The shorthand suggested here is taken from our Using symbols and shorthand in tables guidance.

Machine readability for cells with no data

If you are making a spreadsheet solely for machines to read, it is best practice to leave cells with no data blank and use your metadata file to specify why the cells are blank. More information on how to provide metadata when optimising for machine readability is in the Metadata worksheets section.

Symbols, footnotes and codes

Commonly used footnotes

Commonly used footnotes are things that are often noted on data tables, such as ‘estimated’, ‘revised’ or ‘not available’.

When signposting to this kind of note, it is best practice in terms of accessibility (and arguably, usability) to put as much information as possible at the point of need by presenting the whole word instead of using a symbol or shorthand.

However too many words in a table can cause visual clutter, damaging accessibility and usability. In this case you can use shorthand to communicate a message. For shorthand to be accessible you must present a key to what it means, above the table in a cell in column A so that all users are made aware of the information before they get to the table.

When choosing what shorthand to use, make sure you refer to our guidance on Using symbols and shorthand in tables. Using this guidance will help to ensure consistent shorthand is used across government which is good for accessibility, usability and machine readability.

You should never use superscript text or symbols as your shorthand as these can be difficult for users with low vision to see. Furthermore, screen reader software does not differentiate superscript text from non-superscript text and often ignores symbols completely because it does not recognise them. Therefore symbols and superscript text could fail accessibility guideline 3.1 readable and accessibility success criterion 1.1.1 non text content.

The only acceptable use of superscript and subscript is when communicating scientific notation and measurements. For example, use in chemical names such as carbon dioxide (CO₂) and measurements such as metres squared (m²). In these situations you should still consider if there is another way you could communicate this information.

Detailed footnotes

Signposting with note markers

When signposting to detailed footnotes it has been common practice to use superscript numbers and letters. However as superscript text is likely to fail more than one accessibility guideline we can no longer take this approach.

If we use non-superscript numbers or letters it could make some text very confusing (for example: ‘Number of people in employment1,2’). This may lead us to fail accessibility guideline 1 perceivable and guideline 3.1 readable. Using brackets around note markers (for example: ‘Number of people in employment(1),(2)’) is a bit better, but doesn’t fix everything as screen reader software may ignore brackets.

Therefore, when signposting to detailed footnotes we advise you to:

• write out the word ‘note’, with the number of the note you need to refer to, and put it in square brackets (we advise square brackets for notes and rounded brackets for units to differentiate them in a consistent way), for example: ‘Number of people in employment [note 1]’
• present a list of notes if a cell needs to refer to more than one note – in terms of accessibility it is fine to refer to a list of notes like this: [note 1,2,3,7] but it is better for machine readability to present a list of notes like this: [note 1][note 2][note 3][note 7]’
• if a note is in a column heading, space the text so the note marker sits underneath the column header text and any information about units (you can do this by pressing ‘Alt’ and ‘Enter’)
• for each table that uses notes, mention that notes are used, in a cell in column A above the table and say where the note text can be found (more information about use of cells in column A can be found in the Structure section)
• it is good practice to use the cover sheet to mention notes, where they can be found and how note markers are presented – for example: ‘Some tables refer to notes. When notes are mentioned the note marker is presented in square brackets. The note text can be found in the notes table’ – this tells users what to expect and helps programmers write code that matches what is in your tables (more information on cover sheets can be found in the Metadata worksheets section).
• think about your users when you are deciding where to put note markers:
  • in terms of usability note markers should only be in table titles, column headings, row labels or a notes column – putting them in cells with data causes problems, for example: when summing up columns of data, any cells with text will be ignored
  • in terms of machine readability note markers should only be placed in table titles or note columns – however, best practice for machine readability is to supply the data as a CSVW (CSV on the web) or through an Application Programming Interface (API). Notes are supplied differently when you supply data in these forms. More information is in the Metadata worksheets section.

Placement of detailed note text

It has been common practice to display the content of detailed notes underneath a table. However there are several issues with this:

1. It can take lots of scrolling to get to notes placed under very long tables – this is bad practice for usability and accessibility
2. Notes placed under tables may be missed by some users who are not expecting them to be there.
3. Notes placed underneath a table may need careful (and mostly manual) formatting to be made accessible. See the section on Structure and the section on Metadata worksheets for more information on how written content should be formatted. Without this formatting you may fail accessibility guideline 2.4 navigable.
4. Long, detailed notes may result in a need for horizontal scrolling which is bad practice for usability and accessibility. This may happen because the note will need to be displayed in one cell – you should not use merged cells to present long notes as merged cells fail accessibility guidelines (see the section on Tables).
5. In complex spreadsheets, identical notes are often placed under several tables across many worksheets – this can mean, when certain notes are updated or changed, some are accidentally missed out.

For these reasons we advise you to create a worksheet called ‘Notes’ which contains a table that lists all the detailed notes for the spreadsheet. Notes placed underneath a table will not necessarily fail the accessibility guidelines but they will need careful consideration and, depending on the size of the table and how they are laid out, they may be considered bad practice.

Example of presenting a key for shorthand and notes (ODS, 4.4KB). See also the example spreadsheet on the accompanying resources page for this guidance.

Footnotes for specific cells

Sometimes it is not possible to put a note marker in a title, column heading or row label because it refers to a specific cell. When this happens there are several approaches.

Using narrow columns

When this is the case we have previously advised to put the marker in separate (very narrow) columns, next to the data.

However, we no longer advise this approach. Firstly because in terms of accessibility all these columns would need headers and all the blank cells might need to be marked up. This may make the table very wide and difficult to read.

Secondly, in terms of machine readability taking this approach often means note columns get added in and taken out fairly often. This means the size and layout of tables changes quite a lot which is no good for programmers or Reproducible Analytical Pipelines.

Placing note marker alongside data

We also sometimes see note markers for specific cells placed within the cell, alongside the data. We do not advise this approach because it damages usability. For example, if a user wishes to sum a column of data but some of the cells have note markers in them, these data points will be ignored.

Note:

• We think it is OK to put a note or shorthand marker in an empty cell as these would be ignored anyway.
• This does not apply to unit symbols such as £ or %, these can go in cells with data when they are needed – software should understand that these are unit markers and so will not ignore these data points.

Currently recommended approach

We now advise that you add a notes column to the table, on the right. Note markers or shorthand should go in this column along with information about which cell or cells the note applies to, for example: ‘[note 1] This note applies to B10, C10 and D10’. Many cells in this column may be empty, this is OK as long as you have explained why above the table. See the section on ‘Cells with no data’ for more information.

Communicating the note in this way means you can use colour to emphasise the cell or cells that the note applies to. This is OK in this instance because while the accessibility regulations state colour cannot be used as the only way to communicate a message, it can be used for extra emphasis. However, you still need to check that the colour contrast of the text against the background colour meets the AA level in the accessibility guidelines. More information on checking colour contrast can be found in the Formatting and use of colour section.

Example of using a notes column to refer to specific cells with colour used as emphasis (ODS, 4.67KB).

Use of symbols

As mentioned, you should not use symbols to signpost footnotes because:

• they can be confusing
• screen readers may not recognise them
• users with low vision may not be able to see them
• some screen reader users may have changed their settings to ignore symbols to avoid auditory clutter

If you use symbols it may lead to a fail of guideline 1 perceivable, guideline 3.1 readable, success criterion 1.1.1 non text content and success criterion 1.3.1 info and relationships.

You can still use symbols in some circumstances if you consider how text reads when symbols are missed out. For example, this sentence: ‘Some shorthand is used in this spreadsheet, e = estimated, r = revised’ still makes sense if the equals symbol is ignored.

It is also OK to use dashes and slashes in codes (such as geography codes) as these are needed for consistency.

Deque (a company that helps businesses make their websites and mobile applications accessible) has published research into how different screen reader software deals with symbols. They list 17 characters considered ‘safe’ to use. These include £ and %. But, as mentioned, it is not only screen reader users we have to consider, so it is best to avoid symbols whenever possible.

Please see our more detailed guidance: ‘Using symbols and shorthand in tables’.

Classifications and geography codes

You may need to use classifications or geography codes in your tables.

Some pointers:

1. Use the right codes

Make sure you are using the correct, nationally recognised codes. This is important for usability and machine readability. If you need any help in this area the GSS harmonisation team can provide advice, email GSSHelp@statistics.gov.uk.

2. Classifications, codes and accessibility

Classifications and geography codes are generally fine in terms of accessibility as they are usually strings of letters and numbers. When codes are not just strings of letters and numbers, you should still use them consistently. It is OK to use symbols such as dashes and slashes in this way as that is how the code is constructed.

3. Help users understand codes

It is best practice to link to supporting information for any codes used, either as a note or on the cover sheet (more information on notes and cover sheets can be found in the Metadata worksheets section).

You should also help users understand any changes in codes or classifications – for example, the Geography Code History Database helps users track changes in area codes.

4. Presenting codes in tables

In terms of usability, machine readability and accessibility (success criterion 1.3.1 info and relationships), codes should be in separate cells to the description of the code and the data. For example, country code ‘AD’ should be in a separate cell to the country name ‘Andorra’, and then there should be another cell for the data linked to this country. The row or column containing the codes must be labelled clearly.

Example of presenting country codes (ODS, 6.31KB)

Machine readability – differences in best practice for symbols, footnotes and codes

If optimising data to be solely read by machines, you should be supplying it as a CSVW (CSV on the web) or through an Application Programming Interface (API). Notes are supplied differently when you supply data in these forms. More information on this can be found in the Metadata worksheets section.

Formatting and use of colour

Written content

Written content in your spreadsheets should be treated in the same way as written content in a statistical report. For example, if you use a style guide for your reports, you should use this for any written content in your spreadsheets.

In terms of accessibility, all written content in your spreadsheet should follow the advice in the ‘Making written content accessible’ section of our ‘Making analytical publications accessible’ guidance.

Tagging headings

Worksheet headings and subheadings can be tagged in Excel using “Cell Styles”. This tagging may help users understand the structure of a document. However, we have found some issues with the tagging functionality and assistive technology. More information can be found in the Titles of spreadsheets, worksheets and tables section and the Metadata worksheets section.

Hyperlink text

It is often helpful to link to extra information or related statistics.

Embedding hyperlinks correctly is specifically mentioned in the accessibility guidelines. It comes under success criterion 2.4.4 Link Purpose (In Context) (Level A) and Guideline 3.2 Predictable.

Making hyperlinks accessible

• Use specific descriptions

Hyperlink text should be a specific description of the destination, not just ‘blog post’ or ‘report’. It should never be directional text like ‘click here’.

One of the reasons for this is screen reader software can read out a list of links on a webpage or in a document. This allows visually impaired people to scan content. When link text is not specific, a person cannot easily find a link they may be interested in.

• Do not use URLs

Do not use the URL of a webpage as the hyperlink text, unless it is very short (e.g. www.unsplash.com). Screen reader software often reads out URLs letter by letter. This can be very time consuming and annoying. Also, in most circumstances they do not describe the destination page.

• Say if it opens a new window

Links to different webpages should open in the window the user is on. If a link opens in a new window this should be mentioned in the link text, for example: ‘Find out about government services and information on the GOV.UK homepage (opens in new window)‘.

• Link to documents carefully

If you are linking to a document, it is best practice for the link text to contain the descriptive text, the type of document and its size. For example: ‘Template to report breaches of the Code of Practice for Statistics (ODT, 23 KB)‘.

• Be consistent with signposting

Make sure links to the same destination have consistent text and links with different purposes or destinations have unique link text. It is bad practice to provide lots of links to different destinations with the same non-specific link text, such as: ‘Find out more’.

• Format link text correctly

Link text should be underlined by default. If it is not, the accessibility guidelines say you must consider colour contrast with surrounding text and a “visual cue” that appears on mouse hover and keyboard focus. You may find the WebAim link contrast checker a useful tool.

Example of good practice for links:

You can find more information about accessibility on GOV.UK.

Dates and time periods

It is best practice to format dates and time periods as advised by the Office for National Statistics style guide and Government Digital Service guidance.

This means:

• do not use dashes, use ‘to’, for example, do not use ‘Jan – Mar 2020’ use ‘Jan to Mar 2020’
• it is fine to truncate days and months to save space
• do not truncate years, for example, write: ‘Jan 1931’ not ‘Jan 31’
• when referring to quarters of the year, write out the months, for example, ‘Jan to Mar 2020’ not ‘Q1 2020’ – if your users need Q1, Q2, Q3, Q4 to aid calculations or coding then you must define what this shorthand means in a cell in column A, above the table so a user comes to this information before getting to the table itself.
• if your data needs specific dates, for example: 01/02/10,  you can present them like this but be aware screen readers will read this as ’01 slash 02 slash 10′ which can be annoying and cause auditory clutter, so it is best practice to write the date using words: ‘1 Feb 2010’

Other pointers for formatting that must be followed to meet the accessibility guidelines:

• No visual devices such as colour, shading or patterns should be used to divide up tables – these devices may fail accessibility guideline 1. perceivable if they make content difficult for some users to see.
• No text is set in a vertical or diagonal direction – this is not mentioned specifically in the accessibility guidelines but it may be considered necessary to pass guideline 1. perceivable and guideline 1.4 distinguishable.
• No text has spaces between letters in a word for visual effect as this can be difficult to read and screen readers will read the letters out one by one – this is not mentioned specifically in the accessibility guidelines but it may be considered necessary to pass guideline 1. perceivable.
• Colour is never used as the only way to communicate a message – this fails accessibility success criterion 1.4.1 Use of colour and complicates machine readability.
• Make sure there are no spelling or grammatical mistakes – this will ensure you meet accessibility guideline 3.1 readable – you can run a spelling and grammar check in Excel – in newer versions it is on the ‘Review’ ribbon.
• No columns or rows are hidden from view (guideline 1. perceivable) – if this is needed you will need to give guidance in a cell in column A, above any tables, on what rows or columns are hidden and how to unhide them.

Other pointers for formatting that should be followed in terms of best practice

• While font size is not specifically mentioned in the legislation, we advise you to make text at least size 10, best practice would be to make it at least size 12.
• Consider how your tables are structured – remember it is easier to read down a list than across a table so you may want to think about transposing your data.
• Only use sans serif fonts like Arial or Calibri as people with dyslexia find serif fonts hard to read.
• Avoid the use of underline and italic text – if you need to highlight text it is best to use bold as people with dyslexia can find italic and underlined text hard to read.
• Avoid changing the colour of text to highlight it – if you do this you must check the colour contrast of the text against the background colour (more information on how to do this can be found in the ‘Checking text colour contrast’ sub-section).
• Use the ‘default’ or ‘automatic’ colour settings for all text (except link text or when colour is used for emphasis) – doing this will ensure the spreadsheet takes on the specialised colour settings users of assistive technology may have set up on their software.
• Do not add a background fill – some users will have settings that automatically change the colour of the background to make the content easier for them to read, but this does not happen if you have added a fill colour – even if it is white.
• If you want to give the impression of a plain white background you can turn Excel’s automatic grey gridlines off in the ‘View’ ribbon.
• Avoid adding bold gridlines or cell borders – in general it is better to keep things simple.
• Avoid including images of charts in your spreadsheet, if you do you must carefully consider their accessibility (more information on images of charts can be found in the ‘Images’ section).
• Left align all text in cells outside the table and all row labels within the table.
• Right align all data within a table and all column headings (except the column of row labels or other columns of text).
• Use commas to separate thousands in numbers of four digits or more, and never spaces (for example ‘32,401’ not ’32 401′) – except when writing years – these should have no punctuation.
• Set sensible zoom levels before you save your spreadsheet (this is usually 100% zoom).
• Do not let text run too far across the screen as horizontal scrolling can be tricky – make headings or sentences shorter or split them up over a few rows.

In terms of machine readability you should also:

• avoid using Excel’s indentation tool to indicate subsections or hierarchies (for example indenting a list of regions under a row for ‘England’) – use row height and column width to create white space instead
• ensure no cells with text have ‘hidden’ spaces at the start or end
• check there are no ‘hidden’ spaces in tab labels (a good way to avoid this happening is to put underscores between each word, for example: ‘Top_10_baby_names’)
• consider providing a data Application Programming Interface (API) to aid further analysis

Checking text colour contrast

While colour can never be used as the only way to communicate a message, it can be used for emphasis. When this is done, you must still check the colour contrast between the text and the background is strong enough to meet the accessibility guidelines. You can use the WebAIM colour contrast checker to do this. Remember, legally you need to meet the AA standard.

Be aware that colours are coded in different ways. To use the WebAIM colour contrast checker you will need to know the hex code of the colours. Older versions of Excel will give you the Red Green Blue (RGB) codes – you can use this colour code converter to get the hex codes. Newer versions of Excel will give you the hex codes to use directly.

Accessible colours

Assuming you have left the background of your spreadsheet to ‘No fill’ (which we advise you to do), setting text to the following colour codes is accessible at both the AA and AAA level:

• Blue text with RGB code: (0,0,255) and hex code: #0000FF
• Red text with RGB code: (179,0,0) and hex code: #B30000
• Green text with RGB code: (50,100,5) and hex code: #326405

Images

Images within spreadsheets should be avoided. Generally the best place for any analysis or data visualisations is in HTML.

Departmental logos

We advise that images of departmental logos should not be used. Placing a departmental logo on a cover sheet may fail accessibility guideline 2.4 navigable as these images can make it difficult for users of assistive technology to work out where they are on a worksheet. It is better to write out the name of the government department rather than have it in a logo.

If you cannot avoid it firstly make sure the logo has alternative text attached (accessibility success criterion 1.1.1 non-text content). Secondly, on a cover sheet, all the text should be in column A (as screen reader users who cannot see the layout will often navigate down from cell A1). Any images of logos should be placed to the right of this text so they do not disrupt navigation. More information on what a cover sheet should look like can be found in the Metadata worksheets section.

Images of charts

If you include images of charts, you will need to ensure they are accessible. You should also check your specific departmental guidance on including images in spreadsheets. Some departments may not allow you to publish any images within a spreadsheet document.

Checklist for images of charts in spreadsheets:

• consider the colour contrast of chart elements with each other and the background (see the sub section called ‘Checking colour contrast in charts’ sub section)
• consider any text on the chart – ideally this will be minimum size 12, in a sans serif font with no use of italics or underline
• follow best practice guidance for charts – see our ‘Data visualisation: charts’ guidance
• provide a text alternative

Checking colour contrast in charts

The use of colours in charts is more complex as you have to consider colour contrast between different chart elements as well as with the background. We have published guidance on data visualisation and colours.

Providing a text alternative for images of charts

The fundamental idea behind making images accessible is that whenever there is an image that some people may not be able to see or interpret, it should have a text alternative that serves the equivalent purpose (success criterion 1.1.1 non-text content).

This is often given via the ‘alt text’ field behind an image. But we would advise that it is best practice to supply it as text in a cell, or with basic charts it could be supplied as an accessible table of the data presented in the chart.

Doing it this way means the text alternative is easily available to more people (generally the alt text field behind an image is only easily available to screen reader users).

Providing an accessible table as the text alternative

Example of providing an accessible table as the text alternative to a chart (ODS 18.9KB).

In this example the data the chart is presenting is simple. The accessible table on the same worksheet is the text alternative. The image has the following in the alt text field: “Bar chart of the data presented in Table 1”.

Providing text in a cell as the text alternative.

You may have a chart built from calculations not presented in your spreadsheet. Or you may have a chart made up of columns from several different tables. If this is the case, you need to consider the message a non-disabled user would get from looking at this chart. This message should be communicated through the text alternative.

How best to present this text alternative:

1. Open a new worksheet.
2. Extend the width of column A to a sensible width – remember, do not go too wide as no one likes horizontal scrolling.
3. In cell A1 put a title for the worksheet, it would probably make sense if this was the chart title – mark this up as a “Headings 1” using the cell styles button.
4. In cell A2 put an illustrative sentence outlining what is on this sheet, for example: “This worksheet contains an image of a chart and a text description of this chart.”
5. In cell A3 put the text description of this chart – remember this doesn’t need to outline every data point – just think about the message a non-disabled person would get from this chart.
6. Underneath this text description, paste in the image of the chart – remember you should still follow colour contrast rules as far as possible.
7. Use the alt text field for the image to point to where the text description of the chart can be found, e.g. “A text description of this chart is available on this worksheet in cell A3”.

Flat images of charts or Excel charts?

When using flat images of charts you cannot select any of the chart elements. When using Excel charts, elements of the charts can be selected and edited. Furthermore, they can be read by screen reader software. This can work nicely with a simple chart.

However, when we tested more complex charts with screen reader software it led to confusion. It was hard to tell the difference between the elements of the chart and the software sometimes left the chart altogether without alerting the screen reader user. Therefore, our advice is use flat images of charts and follow the approach to the text alternative outlined here.

Structure

Properly structuring your content is important to meet accessibility success criterion 1.3.1 info and relationships.

Pointers for the spreadsheet as a whole

Provide supporting information

From a usability point of view, statistics should not be completely separated from supporting information. Context and caveats are vital to ensure users have enough information to interpret and make effective use of the data. You should hyperlink to supporting information if it cannot be easily included within the spreadsheet tabs (more information on how to use hyperlinks can be found in the Formatting and use of colour section).

Cover sheet and table of contents

For most spreadsheets it is useful if the first worksheet is a cover sheet which provides information about the data. If your spreadsheet has many worksheets, it is also a good idea to create a table of contents that describes the data within each worksheet.

Simpler spreadsheets may not need a cover sheet or table of contents.

Including a cover sheet and table of contents in more complex spreadsheets will help you to pass accessibility success criterion 1.3.1 info and relationships and success criterion 1.3.2 meaningful sequence.

More guidance on cover sheets and the table of contents can be found in the Metadata worksheets section.

Worksheet names

Ideally each worksheet should have a unique name that clearly describes the information found in that sheet. If this is not possible, give each sheet a number and use your table of contents to describe what is in each worksheet.

To avoid any confusion for assistive technology and to improve usability and machine readability you should:

• check there are no ‘hidden’ spaces in tab labels (a good way to avoid this happening is to put underscores between each word, for example: ‘Top_10_baby_names’)
• keep worksheet names as consistent as you can between releases

Blank worksheets

Remove any blank worksheets. Blank worksheets can be confusing as it is not clear if they are meant to be blank or if something is missing. They may also make navigation confusing for some users leading to a fail of accessibility guideline 2.4 navigable.

Other things to avoid

• Do not use headers and footers to convey important information – this will fail accessibility as screen readers often cannot find the information displayed in spreadsheet headers and footers.
• Do not use floating elements such as text boxes – these will fail accessibility as screen readers often cannot ‘see’ inside text boxes.
• Deactivate any floating toolbars – these may fail accessibility as screen reader software may not be able to access populated cells behind them – if you do need to leave a floating toolbar active then attach it to the other Excel toolbars at the top of the window.

Pointers for structure within worksheets:

Information in column A

Column A is very important for some users. For example, a screen reader will generally start each worksheet by reading out the information in cell A1. Similarly, keyboard-only users will also tend to navigate down from cell A1. Using column A in the following way will make it easier for you to meet accessibility success criterion 1.3.1 info and relationships and success criterion 1.3.2 meaningful sequence.

The key thing to ensure is that the information a user needs to understand the table is positioned above the table, in a place where users are most likely to read it. It is useful to remember that some users cannot scan content easily.

Cell A1 on each worksheet should tell a user what information is contained on that worksheet. Generally, if there is one table per worksheet, cell A1 contains the title of that table.

Cell A2 should be used for description – for example: ‘This worksheet contains one table. Some cells refer to notes which can be found on the notes worksheet’.

If relevant, information about frozen panes, filters and any symbols or shorthand used within the table should also be presented in column A.

If you have several worksheets and they use different sources, a cell in column A should contain information about the source for the table on that sheet. However, if each table in the spreadsheet uses the same source, the information about sources can go on the cover sheet.

Positioning tables on worksheets

Position tables against the left-hand edges of each sheet. Do not leave a blank column as a gap. As mentioned, screen reader users tend to navigate down from cell A1, if they hit blank cells it can be very hard to navigate to where the table is and your spreadsheet may fail accessibility guideline 2.4 navigable.

Below the table

It is best practice to avoid putting any information below a table. It can be difficult to navigate to and may be missed by some users. It will also require mostly manual formatting to ensure it meets accessibility guidelines, which can be time consuming. More information on formatting text in spreadsheets can be found in the Titles of spreadsheets, worksheets and tables section and the Metadata worksheets section.

If a user needs to access information below the table in order to understand the data within the table, it may lead to a fail of accessibility success criterion 1.3.2 meaningful sequence. For example, if you have used some shorthand in your table such as ‘e’ for ‘estimated’ and you only mention what ‘e’ signifies below the table, this could be considered a fail.

Therefore, you should put all information a person needs to know in order to understand the table, in column A, above the table.

When it comes to more detailed notes referring to context and caveats we advise that these should live in a table on a ‘Notes’ worksheet (more information on how to present notes can be found in the Symbols, footnotes and codes section).

Structure for presentation of geographical regions of UK

Example of how to present a UK regional breakdown (ODS, 19KB)

This example shows how to present a UK regional breakdown within spreadsheets in an accessible way. It also shows how to present them as Tidy Data which is useful for machine readability.

The Open Geography Portal has lots more detail on presenting statistical geographies in spreadsheets.

Titles of spreadsheets, worksheets and tables

Titles and headings affect usability, accessibility and machine readability.

Titles and labels are important parts of table design. They help users understand the data. They are particularly important if the table is copied and placed into another context.

In terms of accessibility, if users cannot find or understand the data they need, your spreadsheet may fail accessibility guideline 2.4 navigable and 3.1 readable. It may also fail accessibility success criterion 2.4.6 headings and labels.

It is also important to be consistent when writing titles for spreadsheets, worksheets, tables and column headings. A lack of consistency within a publication and between different releases, limits machine readability.

Pointers:

• Make sure the overall title for your spreadsheet gives a clear description of the data and includes the time period and geographical region the data applies to.
• Use standard and consistent title formats across your publication portfolios and within your spreadsheets.
• It is best practice to have one table per worksheet – this means the title of the worksheet should be the title of the table.
• In large spreadsheets it is a good idea to number your tables, for example: ‘Table 1: Number of people in different age groups, UK, seasonally adjusted’.
• In general the titles of tables should include a description of the data and the geography it applies to, for example: ‘Number and percentage of people aged 16 to 64 in each labour market activity group, UK’
• If your title is very long, split it across a few rows- ideally you want to avoid horizontal scrolling to read a title

Where to place and how to tag titles

To meet accessibility success criterion 1.3.1 info and relationships and success criterion 2.4.6 headings and labels the worksheet title should be in Cell A1.

Ideally the worksheet title should also be marked up as Headings 1 using the ‘Cell Styles’ tool on the ‘Home’ ribbon. This ‘mark up’ may help some users understand the structure of the spreadsheet. However, we have found that current screen reader software does not recognise the heading tags in Excel so it is not essential to tag headings, but it is considered best practice.

Note: headings tags in PDFs, Word documents and webpages are well-recognised by assistive technology so they are considered essential in those formats.

Formatting cells tagged as headings

The Excel default formatting for headings is not accessible. You can either edit each heading manually or modify the default formatting.

If you edit manually you will need to:

• choose the automatic colour setting for the font colour (see the Formatting and use of colour section for more information on why this is important)
• ensure you have chosen a sans serif font in at least size 12 (although for titles a larger size of 14 or 16 is better) – sans serif fonts are easier to read, particularly for people with dyslexia
• remove the automatic cell border – underlined text is harder to read – again, particularly for people with dyslexia and those with low vision

If you want to modify the default headings settings you must:

• Select the cell the heading text is in.
• Select ‘Cell Styles’ in the ‘Styles’ section of the ‘Home’ ribbon.
• Go to the headings style you want to modify (the title of a worksheet should be ‘Headings 1’).
• Right click and select ‘Modify’.
• Select ‘Format’.
• Choose a sans serif font and at least size 12
• Select the ‘automatic’ colour setting
• Go to ‘Borders’ and select ‘None’

Note: these instructions may differ for different versions of Excel.

Metadata worksheets: cover sheet, notes sheet, table of contents

When creating spreadsheets intended for people to open, read and analyse (as opposed to ones made for machines to read), you should include worksheets with information about the data (this is called, ‘metadata’).

Cover sheet

If your data is simple and there is only one table in your spreadsheet, you might not need a cover sheet. However, they are generally useful in most circumstances.

Information to include on your cover sheet

Decisions on what information should go into a cover sheet will vary from one statistical release to the next. It is best practice to include the following information (if applicable to your data):

• The title of the spreadsheet – this should briefly describe the data, the time period covered and the geographical region the data tables refer to.
• A brief summary of what the data tables are about.
• The name of the statistical release the data relates to with a hyperlink to that release.
• The source for the data – if you have a complex spreadsheet with many different tables and sources you can put source information on each individual worksheet (above the table) or have it in a column in your table of contents.
• The date the spreadsheet was published.
• The date the next update to the spreadsheet will be published.
• Information on whether data are provisional or revised.
• Key information users need to know that relates to all (or nearly all) worksheets in the spreadsheet, for example information on weighting.
• Contact details for the statisticians responsible for the data and for media enquiries

You might also want to include:

• information on where to find related data or supporting publications.
• links to a wider data series – although we would advise, wherever possible, to keep time series or historical data in the same spreadsheet
• links to supporting information about the data and methodology documents.
• information on the quality of the statistics
• link to a glossary of essential technical terms and acronyms.

However, if your cover sheet is starting to look like a text document it is best practice to publish this extra information on a webpage instead and link to it. Ideally this will be the webpage where the spreadsheet lives. For more information on this see the Saving and publishing spreadsheets section.

Making cover sheets accessible

Tag titles

To meet accessibility success criterion 2.4.2 page titled the title of the spreadsheet should be in cell A1 of the cover sheet. It is best practice for this title to be tagged as ‘Headings 1’ using the cell styles tool but this is not essential within spreadsheets as we have found issues with assistive technology understanding the tagging in Excel (more information on tagging headings can be found in the Titles of spreadsheets, worksheets and tables section).

Use and tag subheadings

To meet accessibility success criterion 1.3.1 info and relationships and success criterion 2.4.6 headings and labels you should use subheadings to break up the information.

It is best practice for these subheadings to be tagged using the cell styles tool. First level subheadings should be tagged as Headings 2, second level subheadings as Headings 3 and so on. However, this tagging is not essential within spreadsheets as not all assistive technology recognises the heading tags in Excel (more information on tagging headings can be found in the Titles of spreadsheets, worksheets and tables section).

Keep text in column A

It is best to keep all text content in cells in column A. Make the cells a reasonable width to ensure text is easy to read and wrap the text within the cells. You want to avoid users having to horizontally scroll to read the text.

Follow guidance for written content

Make sure all the written content follows the advice in the ‘Making written content accessible’ section of our ‘Making analytical publications accessible’ guidance.

Put hyperlinks in their own cell

While in HTML or in a document format you would highlight the relevant text and make this a hyperlink, in Excel the whole cell becomes a hyperlink regardless of how much text is highlighted. This causes a problem because It can be confusing and disorientating if a user clicks on text that looks normal but then a new window opens up.

An alternative option would be to make all the text in the cell look like hyperlink text but that can then be difficult to read.

Therefore, in Excel it is best to put hyperlink text in its own cell, separate from the chunks of text.

Example of a cover sheet

Example cover sheet (ODS, 34.1 KB)

Table of contents

If you have a lot of worksheets in your spreadsheet you should create a table of contents that describes the data within each worksheet. This will ensure you meet accessibility guideline 2.4 navigable.

This can live within the cover sheet or on its own worksheet, but make sure it is marked up properly as a table and named ‘Table of contents’ (more information on marking up and naming tables can be found in the Tables section). If it is on its own worksheet make sure this is named ‘Table of contents’.

This table of contents can also contain other information such as the source of the data (particularly if several different sources are used throughout the spreadsheet), the date of the last update and the date of the next update.

Hyperlinking from the table of contents to cell A1 of each worksheet also aids navigation around a large spreadsheet but is not strictly necessary if all tables are marked up and named consistently. We would not suggest linking to the tables directly as this may mean users will miss information presented above the table that they need to understand.

Notes worksheet

If certain cells in your spreadsheet refer to notes, it is better for usability and accessibility to create a table of notes that lives in a ‘Notes’ worksheet than to put information underneath each table. More information on this can be found in the Symbols, footnotes and codes section of this guidance.

Remember that the table of notes will need to be marked up and named appropriately.

How to supply metadata if optimising for machine readability

If you are publishing data to be solely read by machines, metadata should be provided via an associated metadata file. For example, metadata for ‘statistics.csv’ should be provided in the ‘statistics.csv-metadata.json’ file. See CSVW (CSV on the web) for an appropriate metadata file specification.

Communicating uncertainty in spreadsheets

When designing a statistical spreadsheet, it is best practice to consider how to appropriately communicate any uncertainty to your users. Bear in mind that the user may not read detailed documents, or they may have copied the spreadsheet to use in another context.

Use the notes worksheet or the cover sheet to:

• make it clear if there are any potential sources of bias or uncertainty – users need to know how this impacts on their use of the statistics
• highlight relevant information about comparability issues both across time and with equivalent statistics released elsewhere in the UK

For more information on the notes worksheet and cover sheet please see the Symbols footnotes and codes section and the Metadata worksheets section.

Confidence intervals

When communicating confidence intervals it is best practice in terms of usability, accessibility and machine readability to put the higher and lower bounds in separate cells next to the data. Make sure all columns have clearly labelled column headings – this is good for usability and essential to meet accessibility success criterion 1.3.1 info and relationships.

Example of how to present confidence intervals (ODS, 4.19KB)

Statistical significance

Note that the credibility of assessing statistics using significance levels is currently under debate.

If you are communicating statistical significance show where a change is statistically significant in a separate cell to the data. In terms of accessibility it is best to do this using words, for example: ‘Significant at 0.001 level’. You must also give the column or row holding the significance information a clear heading.

If it is not possible to use words (for example, if it would take up too much room), you can use letters as shorthand (do not use symbols). To make this accessible you must also provide a key, above the table, in a cell in column A so the user sees this information before getting to the table. See the section on Symbols, footnotes and codes for more information.

The asterisk symbol (*) has traditionally been used to communicate the level of statistical significance. Not all screen readers can understand the asterisk symbol and some users can find them difficult to see and understand. Using them is likely to fail accessibility guideline 3.1 readable. However, if you are creating a spreadsheet solely for machines to read it is OK to use the asterisk symbol, but you should still communicate what this means in a metadata file accompanying the spreadsheet.

Worksheets with multiple tables

In general you should avoid publishing worksheets with multiple tables. These worksheets can be difficult to navigate and are bad practice in terms of machine readability. However, if you have to do this there are a few points to bear in mind to meet accessibility guideline 2.4 navigable and success criterion 1.3.2 meaningful sequence.

Worksheet titles when there are multiple tables

Pointers:

• The worksheet title should be in cell A1
• The worksheet title should describe the data in the tables, for example ‘Number and percentage of population in each labour market activity group by age band, UK, seasonally adjusted’
• The worksheet title should be marked up as a Headings 1 using the ‘Cell Styles’ tool on the ‘Home’ ribbon. Find out more about marking up headings in the Titles of spreadsheets, worksheets and tables section of this guidance.

Normally in large spreadsheets where worksheets are numbered instead of named, the title of each worksheet includes the table number, for example ‘Table 1: Number of people resident in each UK country’. When some worksheets have multiple tables, the worksheet titles cannot refer to specific tables. This means it is best to put the worksheet number in the title instead. For example: ‘Worksheet 1: Number and percentage of population in each labour market activity group, UK, seasonally adjusted’ ‘Worksheet 2: Number and percentage of population in each labour market activity group by age band, UK, seasonally adjusted’ and so on.

Table titles when there are multiple tables

Each table within the worksheet should have a unique title, for example ‘Table 2a: Number and percentage of people aged 16 and over in each labour market activity group’. It is best to have a clear numbering or labelling structure. For example linking the table numbers to the worksheet number, so all the tables on worksheet 2 are table 2a, table 2b, table 2c and so on.

Each table’s title should be in the leftmost cell directly above the table.

Each table title should be marked up as a ‘Headings 2’ using the ‘Cell Styles’ tool on the ‘Home’ ribbon.

Presentation in worksheets with multiple tables

Cell A2 should describe the number of tables on the sheet and how they are presented, for example ‘This worksheet contains eight tables presented next to each other horizontally with one blank column in between each table. Each table applies to a different age group’.

Each table should be marked up and named (more information on this in the Tables section).

The first table on the worksheet should border the left hand edge of the worksheet.

Tables should be separated by a single blank row or column – large gaps between tables could be misunderstood by screen reader users.

Macros, formulas and application code

We advise you to avoid publishing spreadsheets with macros in. It can be difficult to ensure these meet the accessibility regulations and, in general, they are bad for machine readability. They may also be a security risk.

It is also best practice to remove any other formulas or application code contained in your spreadsheet. Formulas and code can cause confusion and they can pose a security risk.

If you have to include formulas or code, ensure they are hard coded to avoid accidental errors in use and check with your IT or security team about the associated risks.

Saving and publishing spreadsheets

Pointers for usability and accessibility:

• Ensure the spreadsheet itself and all worksheets within it, open in a sensible place by placing the cursor in cell A1 on each of the worksheets before you save.
• The final save of the spreadsheet should have the cursor in cell A1 of the first worksheet.
• Zoom should be set to 100% when you save your spreadsheet to ensure no enlargement or reduction is active.
• Avoid zip files as these can be blocked by organisational policies.

Document information

Before saving your spreadsheet you should make sure you have provided clear and useful document information.

The accessibility guidelines require the title field and information about document language to be complete (success criterion 2.4.2 page titled and 3.1.1 language of page). It is usability best practice to also fill in the author and keyword fields.

How to add document information

Go to ‘File’, then ‘Info’ and fill in the following fields:

• Title

Type in the title of the spreadsheet (more information about titles can be found in the ‘Titles of spreadsheets, worksheets and tables‘ section of this guidance).

Do not use dashes or underscores here.

• Author

Generally this should be the organisation that published the document – avoid using names of individuals.

• Keywords or Tags

Put in a list of terms that someone might use to search for the document, separated by commas. This helps search engines find the document. It also helps with finding your document internally.

How to set the document language

Go to ‘File’, then ‘Options’, then ‘Language’. Make sure the document has the correct language(s) selected.

Information to put on the webpage where the link to the spreadsheet lives

Ensure the webpage that houses the link to your spreadsheet contains a clear description of your data and has clear signposts to supporting information. This will help users find, understand and use your data.

The landing page for Conception statistics, England and Wales is a good example of a webpage that hosts links to spreadsheets. It contains:

• a summary of the data
• contact details for the responsible statistician
• a link to the publication that uses this data
• links to methodology information
• a list of spreadsheets split by year

Also, at the bottom of the page it has a section for ‘Important notes and usage information’ which contains related statistics, a user guide and links to statistics for other UK countries.

You may repeat some of this information on the cover sheet of your spreadsheet. This is OK as people may find their way to your spreadsheet in different ways. Some may be sent the document directly, some may go to the webpage and download it from there. For more information on what to put in your cover sheet and how to format it, see the Metadata worksheets section.

File formats

Whenever possible you should publish your spreadsheet in an open format.

This is not explicitly mentioned in the accessibility regulations, but generally, open formats make outputs easier to access because they do not rely on users having specific software.

Furthermore, the Government Digital Service (GDS) recommend using the ODF 1.2 Open Document Format (ODF) standard for sharing and collaborating on documents in government.

Excel formats

Excel files (such as .xls and .xlsx) are not considered to be open formats.

ODS format

For spreadsheets you intend users to read and analyse themselves we advise you use the Open Document Spreadsheet (ODS) format. This is an open format very similar to Excel which GDS recommends.

When you save as an ODS file, Excel will bring up a box to warn you that some features of your spreadsheet may not be compatible with the ODS format. If you want to know more, Microsoft have published information about Excel features that are and are not compatible with the ODS format.

CSV format

The other commonly used open format is Comma-Separated-Values (CSV).

If you are publishing a CSV file that you intend users to read and analyse themselves, it must meet the accessibility regulations. It can be a bit tricky to do this with CSV files as they only allow one tab and will strip out almost all formatting (such as table tags, headings tags and hyperlinks). If you have a very simple spreadsheet it may be possible to make a CSV version meet the accessibility regulations, but for anything slightly complex, we advise you use a different format.

If you are publishing a CSV file solely for machines to read it does not need to meet the accessibility regulations. CSV is the recommended format for spreadsheets optimised for machine readability.

Note: any file you publish online that a non-disabled users can access and understand should have an accessible version that all users can access and understand, even if the original version is optimised for machine readability.

You should be aware of government data standards that may relate to your CSV files. The tabular data standard published by the Government Digital Service in June 2018 was updated in August 2020.

Website support

Be aware that the website you publish on may have restrictions on the type of file formats it supports. Some websites do not yet support the ODS format which may mean you have to publish your spreadsheets in an Excel format for now.

Note that GOV.UK does support the ODS format and the Government Digital Service recommends it.

Publishing alternative versions of the same spreadsheet

If you need to, you can publish alternative versions of the same document. As long as one of them meets the accessibility regulations you are meeting the requirements of the accessibility legislation. You should clearly mark which spreadsheet is accessible and which is not.

For example, you may want to publish an accessible ODS version of your spreadsheet for users to read themselves, alongside a machine-readable CSV version. You may also wish to publish an ODS version alongside an Excel format if that would best meet your user needs.

Software capability

In terms of usability, you should be aware that different spreadsheet tools and software have different capabilities for how they handle data. Check the specifications of your software, particularly around row and column limits, to make sure you are using an appropriate tool.

Note:

• The XLS file format has a row limit of 65,536
• The XLSX file format has a row limit of 1,048,576

If the spreadsheet tool you use cannot hold all your data then you are likely to lose information, which can distort statistics and conclusions.

Read more about Excel specifications and limits.

File names

In terms of usability it is best practice for file names to:

• be unique, for example do not call all your data downloads ‘Data download’
• be descriptive and make sense out of context – for example, tell the user what is in a data download, do not just call it ‘Data download 1’
• be frontloaded
• be short – aim for 60 characters or fewer, including spaces
• avoid acronyms – put these in the document information as keywords or tags
• be entirely lowercase
• use dashes instead of spaces or underscores between words – this makes file names easier to read, for example: ‘a file name.ods’ will end up as: ‘a%20file%20name.ods’ online, which is why it is better to call it ‘a-file-name.ods’
• not include a date, unless the date is part of the document title, for example, ‘Business-plan-for-2016-to-2017’
• be sensible – do not include a version number, names or words like ‘draft’, ‘clean’ or ‘final’, unless those words are part of the document title (for example: ‘guidance-on-making-documents-accessible’ is a more sensible file name than ‘access-guid-final-draft-Han-edit3’)

In terms of accessibility there is not a specific success criterion for file names but following this best practice will help you meet accessibility guideline 3.1 readable and 3.2 predictable.

Sources for this guidance

• Microsoft guidance
• Microsoft video guidance
• SiteImprove guidance
• Guidance from Michigan State University
• Welsh Government guidance
• Information on making tables accessible from Government Digital Service
• Making analytical publications accessible
• Guidance shared with me by the Northern Ireland Statistics and Research Agency (Nisra)
• Feedback from the Digital Accessibility Centre (DAC)

Resources

We have compiled a number of resources to help make your spreadsheets accessible such as checklists, examples and demonstration videos.

Any questions?

If you have any further questions you can:

• email Analysis.Function@ons.gov.uk
• join our Basecamp project for the 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