Before publishing a spreadsheet of data (including as a supplementary table to a written report), consider why you are publishing it and what the best format for it might be.
Where users will want to open, view and read the contents of a spreadsheet in a manual fashion (rather than only wanting to read the data into analytical software), that data should be presented in an accessible ODS spreadsheet file.
The accessibility of a spreadsheet should be considered at each level, from the overall workbook down to individual cells where special formatting might be needed.
This page is based upon a range of sources from across government and beyond. For a reading list, please see the sources section towards the bottom of this page.
Accessibility and different publication formats
Why is accessibility important?
Accessibility means making content clear and easy to find, access, use and understand, for people of all access needs and abilities. Good accessibility brings benefits to all users, improving the quality and value of our statistics, and the trust users have in us as an organisation. It is particularly important for people with disabilities, remembering that 20% of the working-age population report having a disability.
For public bodies, making online content accessible is also now mandated by law. The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, building on the Equality Act 2010, requires that all content published online by public bodies must be accessible in ways that make them “perceivable, operable, understandable and robust”. In the Code of Practice for Statistics, there is a similar requirement that data and related guidance should be easily accessible to users, considering the needs of a range of users, using accessible communication formats.
Publication formats
There are 3 main types of tables that might be produced, each of which lend themselves to different publication formats. You should first consider which of these formats are the most appropriate for what you are trying to achieve through the presentation of your data.
Demonstration tables
These are used to help make or reinforce a particular point in a clear and simple way. They are best placed in the body of a report so that users can access the information quickly, and do not need to leave the page to find it.
Reference tables
These are used to provide more detailed data for users to see, at a level that might be too much for including in the body of a report. They should be provided alongside a report in an accessible ODS spreadsheet format.
Machine readable datasets
These are specifically used to allow users to carry out more detailed analyses of their own on the data, or for merging with other datasets. They are best provided in a CSV spreadsheet format that is optimised for machine readability, for example, to load into R or Python.
It is important to further note the distinction between reference tables and machine readable datasets, and their different accessibility requirements. Specifically:
wherever you might expect users to want to open, view and read the contents of a spreadsheet in a manual fashion, you should provide that spreadsheet in an accessible ODS format (open formats such as ODS do not rely on users having access to specific software such as Excel)
where you would only expect users to want to load your spreadsheet into analytical software for more detailed analysis, or to combine it with other datasets, accessibility legislation does not apply; in those cases, CSV files can be used, accompanied by a JSON metadata file for information about the data
in some cases, you may need to provide both file formats (ODS and CSV), to offer one version that is accessible for users to view the contents, and one version that is optimised for machine readability; we would advise, however, that this approach should be taken only when a CSV file is a key user need as it can cause version control issues and complicate the user journey when the same information is presented in two different formats
XLS and XLSX files should be avoided in all cases as they are neither as accessible as ODS files nor as optimised for machine readability as CSV files.
Note that while machine readable datasets are not subject to accessibility legislation, this does not mean that you should ignore usability. Equally, when presenting data in ODS format, you should still try to bear good machine readability in mind, so that users can load your data into analytical software should they wish to do so.
Detailed guidance for accessible reference tables
The main focus of the current guidance is on reference tables as those will be used for most statistical releases.
The guidance in this section is derived from multiple sources which contain more detail than that presented here. In particular, see:
Note that we will only focus on the more common issues we tend to observe and the citations provided may help you find more exhaustive advice. UKHSA colleagues can contact us via UKHSA_HOPSTATS@ukhsa.gov.uk for any specific questions not answered here.
Many of the same principles presented here will also apply to demonstration tables found within reports and to machine-readable datasets. UKHSA colleagues can again contact us for advice on these if needed.
In the sections to follow, we give detailed guidance on what you need to do to make a spreadsheet accessible. In each sub-section, a checklist of key points is provided first. More detailed information is then given beneath each checklist to explain each point.
Tools for automating accessibility
Some tools have been developed that can help automate the production of accessible reference tables, such as the ‘a11ytables’ (accessibility tables) package for R, and the ‘gptables’ (good practice tables) package for Python. Both have been produced by the Government Analysis Function. These are not intended to produce perfectly accessible tables, so do still require human input and review, but they may help automate many of the required features, in line with the principles of Reproducible Analytical Pipelines (RAP).
For UKHSA colleagues wanting support on implementing these packages, please contact UKHSA_HOPSTATS@ukhsa.gov.uk.
Formatting a workbook
Checklist
A workbook is a file that contains multiple worksheets (tabs). Every workbook should:
be provided in an ODS file format
include clear and useful document metadata
provide a cover sheet containing information about the data
avoid the use of images such as charts
not have any floating text boxes
Reference tables, particularly those for publication on GOV.UK should be presented in an ODS file. This is so that specific software is not needed to open them, which can be a barrier to some users.
You can produce an ODS file from Excel via “File” and “Save As”, then choose “OpenDocument Spreadsheet (*.ods)“.
Providing clear and useful metadata helps users to find your content via search engines, which use this information to rank search results.
To edit metadata in Excel, you should go to “File”, “Info”, “Properties” (on the upper right hand side of the screen), “Advanced properties”.
Under “Summary”, you should add:
the correct document title in the “Title” box
your organisation (for example, “UKHSA”) in the “Author” box (avoid using names of individuals)
The full title, then keywords from the title and subject matter separated by commas, in the “Keywords” box
A cover sheet is important as it helps convey information about the data to users.
All cover sheet content should be kept in Column A, not in a floating text box or in other columns, for good accessibility.
Cover sheets should include:
the document title
a brief summary of contents including links to a report or other background information
a table of contents (with hyperlinks to other tabs)
your organisation and contact details
version information (if applicable)
a publication date
Other information might also be given. For example, notes might be included to explain the data source and any caveats or other important information. Notes should explain any shorthand used throughout the workbook, although any shorthand used in specific tables may be best explained on those tabs instead.
Avoid including images in spreadsheets as they can complicate navigation for some users of assistive technologies. If charts are needed, they are best placed in a separate report document. Departmental logos are usually not needed as departmental names can be stated in text instead.
Screen reader software often cannot access content inside text boxes so these should not be used. Instead, keep all content within spreadsheet cells.
Formatting worksheets within workbooks
Checklist
By worksheet, we mean each tab of a workbook. Every worksheet should:
have a descriptive tab name
have a descriptive title, and subtitle if needed
contain any notes and explanations of shorthand above the table(s)
have only one table, or otherwise be clear how many tables there are
not use blank rows or columns for separation
not have “freeze panes” enabled
avoid anything beneath the table
Tabs should be named to give some indication of their content for easier navigation. For example, “Table_1_Infections_by_age”.
Having a descriptive title and subtitle helps the user quickly understand the content.
Screen readers usually navigate down Column A first so everything a user needs to know should be in Column A. Cell A1 should therefore be the table title; Cell A2 should contain the subtitle where needed.
Notes can be used to give more information about the data. Shorthand might also need to be explained, including what the shorthand looks like and where to find it in the table.
It is important that this information is presented in Column A only, and notes should always be above the table to ensure that they are not missed (which can easily happen if they are presented beneath a table, particularly a long one). Each subsequent note should be on a new row.
Where the same notes apply to multiple tabs, you may decide to explain those notes either on the cover sheet or a separate notes tab instead of above each individual table. If you do this, you should still explain above each table where explanations of notes can be found. For example: “Some cells refer to notes. An explanation of these can be found on the separate notes tab.” It is best not to add hyperlinks when doing this as it can get annoying for the user when those hyperlinks are accidentally triggered, especially when your workbook contains multiple tabs.
Ideally, each worksheet should only have one table as this makes the content very clear for users (additional tables might be missed) and having a single table per tab is also better for machine readability.
However, there may be cases where multiple tables per worksheet might be needed, such as when tables are strongly grouped or where there would otherwise be a large number of tabs in the workbook. In those cases, you should give a worksheet title describing the tables contained within the sheet, with “This worksheet contains 3 tables” (for example) in Column A, immediately beneath the title and subtitle. Each table should then be given a separate table number of “Table 1a”, “Table 1b”, and so on (noting that a descriptive title should also be given for each).
Remove all blank rows or columns as they can make a spreadsheet difficult to navigate. If you want to create separation between elements, instead adjust the row height or column width, and then re-align the text as necessary to achieve the desired visual separation.
Do not freeze rows and columns as this can limit the amount of usable space the user has to navigate the content. This can be a particular issue for users who need to zoom in a lot, or for those using mobile devices with smaller screens.
Note that freeze panes also disappear when saving as an ODS file, which is the recommended file format.
All content should be kept within or above the table, not below it. This is because content beneath a table (such as notes) can be easily missed. See the section above on notes and multiple tables above for more information.
Formatting tables within worksheets
Checklist
By table, we mean the group of cells containing data, including the header row. Every table should:
be marked up as a table
have a meaningful name in the table meta information
have only one header row, with a title in every cell, in bold font
not have split or merged cells, blank rows or columns, or hidden rows or columns
be presented in long format in preference to wide format
avoid very wide columns and wrap text for narrower columns so that it does not get cut off
left align cells containing text; right align cells containing numbers
avoid macros
present rows in a logical order, such as alphabetically or ordinally
carry out and include relevant calculations for the user, such as totals and percentage changes
not use colour as the only way to communicate information
not have filter options enabled
avoid presenting totals in the middle of a table (for example, after each group)
‘Marking up’ tables is essential for users of assistive technologies as it helps them navigate the content. Defining the header row enables the software to read out the column header alongside each data point, which again helps with navigation.
You can tell a table has already been marked up when the “Table design” tab appears in the ribbon after selecting a table cell.
To mark up a table in Excel:
Highlight the table you need to mark up.
Press Ctrl + T.
Make sure “My table has headers” is ticked and press OK.
Select a table cell.
On the Table Design tab, apply the “None” table style for plain formatting.
On the Data tab, deselect “Filter” to remove the filter arrows (these can obstruct content).
Giving a meaningful name here can help with navigation, particularly for users of assistive technologies.
In Excel, you can name a table by clicking on a table cell and then “Table Design” in the ribbon (after marking up the table; see the section above). You will then see a “Table Name” property.
Note that words need to be separated by an underscore here, as spaces are not allowed. For example: “Table_1_Infections_by_age”.
Because the above navigation features only work on a single header row, it is important not to have any secondary header rows. These also cause complications for machine readability.
Where needed, multiple pieces of header information can be combined into a single row through the use of colons. For example, “Heading level 1: Heading level 2”.
Ensuring that every column has a heading is important for accessibility and usability. Bold text helps the header row stand out from the rest of the table.
Having blank rows or columns, or split or merged cells in a table is bad for accessibility as it makes the content harder to navigate, particularly for users of assistive technologies but also for other users as well (for example, those wishing to load your data into analytical software).
If you wish to apply some visual separation between rows or columns, you should instead adjust the row height or column width, changing the text alignment as appropriate.
For similar reasons, you should also avoid hidden rows or columns as these can cause confusion for all users.
A tall narrower table tends to be easier to read and navigate compared to a short wider one. This is because users usually find it easier to scroll down content, rather than scrolling across, particularly on mobile devices.
Keeping columns relatively narrow also makes it easier to navigate the content by cutting down on the need for horizontal scrolling. You should, however, ensure that no text is hidden from users by being cut off in a narrow column. You can wrap text to avoid this.
Right aligning numerical columns helps users more quickly identify different sized numbers as the tens, hundreds, thousands and units are on top of one another. This is particularly important when negative numbers are present, as these do not follow this pattern when left aligned.
Macros in spreadsheets might be difficult to access for certain users, such as those relying on assistive technologies and those that only use a keyboard. Macros can also be confusing for any user when it is not clear how they work. It is therefore best to avoid these, providing static tables instead.
An online interactive dashboard can be used if the interactivity is important.
Columns and rows should be presented in a logical order, for example alphabetically or ordinally. This allows users to find the information they need quickly.
Performing calculations such as totals, averages and percentage changes for the user prevents them from having to do it (and potentially making errors in the process).
The use of colour to communicate information can be difficult or impossible to access for some users with visual impairments, so should be avoided.
Colour can be used for emphasis (for example, to highlight cells affected by notes), so long as the colour contrast is good and users do not need to rely on colour alone to access the information being conveyed by the colour. For example, when presenting a coloured heatmap, numerical values should also be presented within each cell.
Enabling filter dropdown options can obscure content in the header row. It is therefore best to disable these by default. The user can always enable filtering themselves if they wish.
Total rows should not be presented in the middle of a table. This is because they can be easily passed over by the user and might be accidentally included when calculating column totals, for example.
Formatting cells within tables
Checklist
Some formatting requirements may apply to individual cell contents. Cells should:
only contain numbers in numerical columns (except to say that a number is not applicable, not available or has been suppressed)
only communicate a single number in each cell
avoid the use of symbols for shorthand
comma separate numbers in the thousands
precede decimals of less than 1 with a zero
Ensuring that numerical columns do not contain non-numeric characters helps ensure that the data is machine readable and that any calculations performed on that column are done so correctly.
Where a cell contains any characters or symbols (for example, a number with an asterisk), that cell will usually be omitted when a user tries to sum that column, or calculate an average, leading to incorrect results. Any notes relating to specific cells should instead be provided above the table, or in a separate “notes” column, alongside but separate to the numerical data column.
Shorthand used to denote an omission (for example, due to missing data, or because a value has been suppressed to protect confidentiality) is acceptable within numerical columns. This is because those cells would not need to be included in any calculations.
If you are presenting multiple numbers, such as a value followed by its upper and lower confidence interval limits, it is best to place each of these numbers in separate columns. This helps to avoid any confusion as to what the numbers mean but more importantly it enables better machine-readability, removing the need for the user to try and separate out the different numbers through code.
Symbols, such as asterisks, and superscript text, often go against accessibility requirements. This is because symbols are often skipped over by assistive technologies such as screen-reader software, and asterisks and superscript text can be difficult to see for people with visual impairments. Symbols can also be confusing for all users when their meaning is not made clear.
Instead of symbols, letters or short words within square brackets should be used, such as “[x]” or “[note 1]”. Where multiple notes need to be referenced, they should be presented in their own brackets as “[note 1][note 2]”, rather than “[note 1,2]”, as this is better for machine readability and it is less likely that users may skim over the fact that 2 notes have been given.
Widely recognised unit markers such ‘%’ and ‘£’ may be acceptable for accessibility as they are recognised by most assistive technologies. However, it may be better to present unit information within the column header rather than against each value, so as to not affect the machine readability of numerical columns.
[c] = confidential (for example, when suppressing values for statistical disclosure control)
[e] = estimated
[k] = zero when rounded (for example, when rounding down values to zero, to separate these values from true zero)
[x] = not available
[z] = not applicable
Numerals can be added to make more notes of the same type. For example, if 2 cells were estimated for different reasons, you can present “[e1]” and “[e2]”, with the differences explained above the table or on the coversheet.
Note that “[NA]” is discouraged as it is ambiguous: it could mean not applicable or not available.
Academics often use asterisks to denote statistical significance but these are not accessible for the reasons already explained. Instead, it is recommended to either state significance in words (“Significant at 0.001 level”), or to use accessible shorthand as follows (from the same Government Analysis Function guidance on use of shorthand):
[ns] = not statistically significant
[s] = significant to 0.05 level
[ss] = significant to 0.01 level
[sss] = significant to 0.001 level
Using consistent shorthand across all of our publications is a good thing because it increases understanding, makes it easier to compare different datasets, reduces risks of misinterpretation, and helps improve accessibility. Each of these points make for better and more efficient product for the user.
It is best to provide shorthand alongside table titles, column headers, row labels or in a separate notes column. They should not be in numerical cells as those values would then be ignored in any calculations performed by the user, unless they denote a missing value. Where notes or other shorthand apply to the whole table, or entire columns or rows, they can be explained above the table, or on the cover sheet or a separate notes sheet if they apply to multiple tables. Where they apply only to specific cells, they can be explained in a separate “notes” column next to the numerical column, containing text such as, “[note 1]: For cells A5 and B5, note that…”.
Comma separating numbers in the thousands is advised because it helps the user to more quickly identify differently sized numbers.
Preceding decimals with a 0 makes it clear that these are decimal values. Otherwise, users may miss the decimal point, misinterpreting them as integer values.
