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 be aware that 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).
We have created some checklists for making spreadsheets accessible and optimised for machine readability. These should be used alongside this guidance.
- Making spreadsheets accessible: a checklist of the basics
- Making spreadsheets optimised for machine readability checklist (coming soon)
Accessibility, usability and machine readability
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.1. This is a legal requirement set out in The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
Some of the Web Content Accessibility Guidelines (WCAG) 2.1 are generic in nature. Throughout this guidance, using our knowledge, research and interpretation of WCAG 2.1, 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.
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.
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 optimsed for machine readability.
We outline when the advice relates to machine readability and when there are possible clashes with the accessibility advice.
Example of an accessible spreadsheet
We have applied our accessibility guidance to a spreadsheet containing a summary of labour market statistics, published in December 2020 by the Office for National Statistics (ONS).
We hope this example will help you understand and apply this guidance. We have addressed four of the worksheets in this large and complex spreadsheet.
The Digital Accessibility Centre (DAC) have audited this edited version and are happy that it meets all the accessibility guidelines.
The feedback from DAC’s accessibility tester illustrates the frustrations many users of assistive technology normally have with spreadsheets:
“When using the spreadsheet with [screen reader software] JAWS and NVDA I found it to be a pleasant experience. In the past I have found spreadsheets to be extremely confusing, disorientating and stressful. In part this stress came from having to make the document partially accessible for my own needs.
If all spreadsheets were created with as much care and attention to detail, I may not be as reluctant to work with them as I am today.”
If you want to see what this spreadsheet looked like before the guidance was applied, the ONS labour market summary datasets webpage has a link to it.
Demonstration of how to make a spreadsheet accessible
A demonstration of how to apply this guidance to make a spreadsheet accessible is available on the Government Analysis Function YouTube channel.
You can also download the baby names spreadsheet considered in this demonstration (ODS, 18.4KB).
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?
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 the statistical report, ideally in the HTML of the webpage the report sits on. 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 ‘Introduction to data visualisation’ guidance and our ‘Making analytical publications accessible’ guidance.
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 (more information about this in the ‘Naming tables’ section)
- 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.
At the moment this is a manual process, but we are researching ways to automate it.
- Select the cells you want to include in the table.
- On the ‘Insert’ ribbon, select ‘Table’.
- In the ‘Create table’ dialog box, check the ‘My table has headers’ box
- 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:
- Click somewhere in the table
- Click the ‘Design’ ribbon.
- 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’).
- Uncheck the ‘Filter Button’ box in the ‘Table Style Options’ section.
- 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 the one above the row labels – this should be left aligned)
Adding headers to a table that is already marked up
If the table is already created and you want to tag the header row:
- Place the cursor anywhere in the table.
- Click onto the ‘Design’ ribbon.
- Check the ‘Header Row’ box.
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
- Click anywhere in a marked-up table
- Click the ‘Design’ ribbon
- In the ‘Properties’ section there is a box to edit the table name
- 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.
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 space you can do this by adjusting column width and row height instead.
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.
- 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 put information about units or notes in the column heading cell (more information on how to do this in the ‘Units’ section).
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 the columns in these worksheets 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 tabs 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.
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 + Enter’ 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).
It is important to ensure all text in cells within a table 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.
This is important because users with dyslexia can find it difficult to read crowded text. It is also 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.
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.
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 ’32 401′)
- right align the figures and the column headings
- start numbers of less than one with a zero, not a decimal point
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.
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).
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.
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.
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.
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:
- There is only one reason a cell in a table may be left blank
- The table is marked up correctly (as described in the tables section of this guidance)
- 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 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 statistics and analysis.
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.
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
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 practise 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 to 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.
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 – for example, write ‘[note 1][note 2][note 3]’ if a cell needs to refer to notes 1, 2 and 3.
- try to always put notes in table titles, column headings or row labels – putting them in specific cells may not fail accessibility but it does cause problems for machine readability and usability
- 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 mention notes, where they can be found and how note markers are presented on the cover sheet – 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).
Placement of detailed notes
It has been common practice to display the content of detailed notes underneath a table. However there are several issues with this:
- It can take lots of scrolling to get to notes placed under very long tables, particularly for some disabled users – this is bad practice for usability and accessibility.
- Notes placed under tables may be missed by some disabled users who are not expecting them to be there.
- 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.
- 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).
- 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.
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 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 because 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.
In terms of accessibility we now advise that you add a notes column to the table, on the right. Note markers 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’.
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.
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
Therefore, if you use symbols to signify notes it may lead to a fail of a number of accessibility guidelines and success criterion, including guideline 1 perceivable, guideline 3.1 readable, success criterion 1.1.1 non text content and success criterion 1.3.1 info and relationships.
However, while signposting with symbols is generally a fail of the accessibility regulations, you can still use symbols in some circumstances. 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 best to consider how your text reads if you miss out any symbols.
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 when using their default settings. They list 17 characters considered ‘safe’ to use. These include £, %, & and /. But, as mentioned, some users may have changed their settings from the default so in general it is best to use letters or words instead of symbols wherever possible.
It is OK to use dashes and slashes in classifications and geography codes as these are needed for consistency.
We are aware that this advice goes against our previously published guidance on Using symbols in tables and we have now updated it.
Classifications and geography codes
You may need to use classifications or geography codes in your tables.
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 harmonisation leads in the Best Practice and Impact team can provide advice, email firstname.lastname@example.org.
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 here 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.
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 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.
A key part of this is tagging headings and subheadings correctly (more information on doing this in spreadsheets can be found in the Titles of spreadsheets, worksheets and tables section and the Metadata worksheets section).
It is often helpful to link to extra information or related statistics.
When it comes to accessibility, embedding hyperlinks correctly is specifically mentioned in the accessibility guidelines. It comes under accessibility success criterion 2.4.4 link purpose (in context) 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’ and never directional text like ‘click here’. Bear in mind that screen readers can be programmed to read out a list of links within a document (much like a sighted user would scan a page for links). When link text is not specific, a sighted user can read the surrounding text, a screen reader cannot. This means the links will be difficult to tell apart so the screen reader user will not be able to 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 readers read out long URLs in full, letter by letter. This can be very time consuming and annoying. Also, in most circumstances they do not describe the destination page.
- Linking to documents
If you are linking to another document the link text should 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)‘.
- Consistency in signposting
Make sure that links to the same destination have consistent text and that links with different purposes and destinations have different link text. For example, it is bad practice to provide lots of links to different destinations with non-specific link text like ‘Find out more’.
- Formatting link text
Link text should be underlined by default. If it is not underlined the accessibility guidelines say that you have to consider colour contrast with surrounding text and a ‘visual cue’ that appears on mouse hover and keyboard focus.
Bear in mind that, while not a necessity in terms of the accessibility guidelines, it is best practice for hyperlink text to be both underlined and have the correct amount of colour contrast with the background and the surrounding text. The WebAim link contrast checker is a useful tool.
Dates and time periods
- 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 ‘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 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 – people with dyslexia can find italic and underlined text hard to read, if you need to highlight text it is best to use bold.
- Avoid changing the colour of text to draw attention to 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 grid lines 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, particularly the colour contrast between chart elements (more information on how to do this can be found in the ‘Checking colour contrast in charts’ sub-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).
- 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.
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’)
- 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. Excel will give you the Red Green Blue (RGB) codes – you can use this colour code converter to get the hex codes.
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
Checking colour contrast in charts
The use of colours in charts is more complex as you often have to consider colour contrast between different chart elements as well as with the background. Our data visualisation guidance and the style guide from the Office for National Statistics both have useful tips on this area but neither have yet been fully updated with regards to the accessibility guidelines. We are planning on looking into this in more detail soon.
Images within spreadsheets should be avoided.
This includes any departmental logos. 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, make sure all logos, graphics, charts and any other images within the spreadsheet document have alternative text attached to them (accessibility success criterion 1.1.1 non-text content).
On a cover sheet, all the text should be in column A (as disabled users normally 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 in the Metadata worksheets section.
If you include images of charts, you will need to ensure they are accessible. You will need to consider the colour contrast of chart elements with each other and the background (see the sub section called ‘Checking colour contrast in charts’). You will also need to 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. Images of charts should be placed on a separate worksheet to any tables.
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.
How to add alt text for charts and images
- Right click on the image or chart and select ‘Format Picture/Chart Area’.
- Go to the size and properties box and select ‘Alt text’.
- Enter a title and description for your alt text in the boxes and select ‘OK’.
On newer versions of Excel you may just need to right click and select ‘Edit Alt Text’.
If an image is just decorative you should mark it as such by ticking the ‘Decorative’ checkbox (Excel 2013 does not let you do this but later versions do).
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.
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
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 disabled 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 disabled 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 disabled users are most likely to read it. It is useful to remember that many disabled users cannot scan content in the way other users can.
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 disabled 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 disabled 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).
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.
- 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 porfolios 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’
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 and should be marked up as Headings 1 using the ‘Cell Styles’ tool on the ‘Home’ ribbon. This ‘marks up’ the heading which helps assistive technology navigate around the spreadsheet.
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.
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’).
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
To meet accessibility success criterion 2.4.2 page titled the title of the spreadsheet should be in cell A1 of the cover sheet. This title should be tagged as ‘Headings 1’ using the cell styles tool (more information on tagging headings can be found in the Titles of spreadsheets, worksheets and tables section).
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. These subheadings should 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.
Make sure all the written content follows the advice in the ‘Making written content accessible’ section of our ‘Making analytical publications accessible’ guidance.
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.
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.
We are developing guidance on how to best provide metadata for datasets optimised solely for machine readability.
Communicating uncertainty in spreadsheets
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
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.
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 many disabled users can find them difficult to see and understand. Using them is likely to fail accessibility guideline 3.1 readable. However, if you a 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 pratice 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
- 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 is 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.
Newer versions of Excel have a built-in accessibility checker. You can use this to see what issues it flags up. But remember it is a bit like using a spelling and grammar check. It is likely to miss some things and it may bring up things that are not relevant.
For example, the checker may flag up tables that do not have alt text. As long as your tables are marked up and named correctly you do not need to add this in. In any case, it will be removed if you save your spreadsheet in an Open Document Spreadsheet (ODS) format (which we recommend you do if the website you publish on supports this file type).
To run the accessibility checker, go to the ‘Review’ ribbon and select ‘Check Accessibility’.
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
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:
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.
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.
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 more accessible because they do not rely on users having access to 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 files (such as .xls and .xlsx) are not considered to be open formats.
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.
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 to 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.
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.
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 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.
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.
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.
For example, older versions of Excel (97-2003) have a row limit of 65,000 rows. You can read more about Excel specifications and limits if you need to.
If the spreadsheet tool you use cannot hold all your data then you are likely to lose information, which can distort statistics and conclusions.
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’)
Sources for this guidance
- Royal National Institute for the Blind spreadsheet guidance (doc, 191KB)
- 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 (Government Statistical Service guidance)
- Guidance shared with me by the Northern Ireland Statistics and Research Agency (Nisra)
- Feedback from the Digital Accessibility Centre (DAC)