Making analytical publications accessible

Policy details

Metadata item Details
Publication date:29 October 2020
Author:Good Practice Team
Approver:Best Practice and Impact Division
Who this is for:Producers of statistics and analysis

Review frequency:


Accessibility: what is it and why should we address it?

“Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the web.”

                                                                                            World Wide Web Consortium

Accessibility of content published on public sector websites has risen in importance in recent years due to the UK accessibility legislation. To find out more about this and what it means for producers of government analysis and statistics, please see our guidance on ‘Accessibility legislation: what you need to know‘.

Back to top of page

What this guidance covers

This guidance aims to help producers of government analysis and statistics meet the UK accessibility regulations.

It does not cover everything you could do to make content accessible. Assistive technology is always adapting and research into barriers disabled people face is increasing. We will update this guidance to reflect new findings.

The guidance does not cover technical aspects of a website such as buttons, online forms and colour contrast in website branding.

Depending on where you publish your content you might have specific guidance to follow. For example, the Government Digital Service (GDS) has guidance for publishing on GOV.UK. Similarly, the Office for National Statistics (ONS) has guidance for publishing on the ONS website.

We try to highlight differences between the GDS and ONS guidance when appropriate. We also try to make it clear when the guidance is directly linked to the accessibility regulations or simply best practice.

Remember, legally, if you publish content on a public sector website, you must meet the AA standard of the Web Content Accessibility Guidelines (WCAG) 2.1. For more information on this please see our guidance on ‘Accessibility legislation: what you need to know’.

Back to top of page

Making written content accessible

This advice will align to most website style guides but remember to check the specific style guide for the website you are publishing on.

Some of the advice here is best practice and some is specifically mentioned in the accessibility guidelines which support the accessibility regulations. We have noted when the latter is true.

Remember, generally speaking, anything that improves consistency across a website makes it more accessible.

Acronyms and abbreviations

Expand acronyms and abbreviations when you first use them.

This is a AAA standard in the accessibility guidelines.

Example of bad practice:

This seminar is the latest in a series organised jointly by the RSS, the RES, ESCoE, ONS and the SPE.

Example of good practice:

This seminar is the latest in a series organised jointly by the Royal Statistical Society (RSS), the Royal Economic Society (RES), the Economic Statistics Centre of Excellence (ESCoE), Office for National Statistics (ONS) and the Society of Professional Economists (SPE).


The Government Digital Service (GDS) states that you can use an acronym on GOV.UK without expanding it on first use if you can prove that 80% of the UK population will understand it without the full version. Examples include: BBC, NHS, PhD and MSc.

Do not use full stops in abbreviations. For example, use BBC, not B.B.C.

If a page is very long, expand acronyms on their first use within each section as users often skim read and skip to sections lower down.

Bold, italic and underline

Bold text

Bold text does not fail accessibility standards and the British Dyslexia Association recommends using bold to highlight text for people with dyslexia. On the other hand, bold text used for emphasis can sometimes make content difficult to read for people with visual impairments.

Using bold text for emphasis is not permitted on GOV.UK.

Please check the style guide for the website you publish on.

Italic and underline

Do not use italic fonts or underline words to draw them out of text. This makes content hard to read for people with dyslexia. The only things you should underline are hyperlinks.

Bullet points

Be consistent in presentation of bullet points. We recommend the GDS style guide advice for bullet points.

Capital letters

Too many capital letters make sentences hard to read, particularly for people with dyslexia.

We recommend you follow the GDS style guide advice on capitalisation.


Avoid using negative contractions such as ‘can’t’ or ‘don’t’.

These can be easily misread by people with dyslexia and those who do not have English as a first language. Research has found these users tend to read up to the positive (for example: ‘can’), but do not read the apostrophe t at the end.


Write dates in this order: date, month, year. If the day of the week is relevant, put it before the date.

Do not use ‘st’, ‘nd’, ‘rd’ or ‘th’.

Examples of good practice:

12 March 2014.

Monday 3 March 2014.


Write out months in full, unless space is an issue (for example, in tables or publication titles).

We recommend you follow the GDS style guide advice on dates.

Email addresses

Be consistent in how you embed email addresses.

We recommend you write email addresses in full and as active links. This means the link will automatically open the default email provider. Do not include any other words in the link text.

Use capital letters to break up the words. For example, write instead of

This is because screen readers are more likely to read the content correctly if capital letters are used in this way.

This is an update to our original advice so you may find email addresses across the GSS website still written in lowercase at the moment.

Example of good practice:

Contact for more information.


All fonts should be sans-serif. Sans-serif fonts are easier to read for people with dyslexia. Some of the most popular sans serif fonts include Arial, Century Gothic and Calibri.

Do not highlight words in text by:

  • using different fonts
  • using coloured fonts

It is best practice to use one font consistently across a website or publication.


Jumping from one section of text to another can be disruptive for all types of user. You should aim to put the information at the point of need whenever possible.

We know this is more difficult when it comes to data tables. More detailed advice for footnotes on data tables can be found in our ‘Releasing statistics in spreadsheets’ guidance.


Headings and subheadings must be clear, descriptive and tagged correctly so that screen readers can understand how content is structured.

This is specifically mentioned in the accessibility guidelines. It comes under success criterion 1.3.1 Info and Relationships (A standard) and success criterion 2.4.6 Headings and Labels (AA standard).

The publication title should be tagged as H1, first level subheadings should be tagged as H2, second level subheadings should be H3 and so on.

You will need to find out how to tag headings and subheadings whether you are publishing directly onto a webpage or creating a document for publication. There is more on tagging headings in document formats in the ‘Making document formats accessible’ section of this guidance.

Hyperlinks (links to other webpages)

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

Making hyperlinks accessible

  • Use specific descriptions

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

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

  • Do not use URLs

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

  • Say if it opens a new window

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

  • Link to documents carefully

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

  • Be consistent with signposting

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

  • Format link text correctly

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

Example of good practice:

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


Be consistent when you write about numbers.

If you publish on GOV.UK you must ensure you follow the GDS style guide advice on numbers.

If you need more specific advice, we recommend the ONS style guide section on writing about numbers in statistical publications.

Quotes and speech marks

To be consistent across your publications we recommend you follow the GDS style guide advice when it comes to speech marks and quotations.

Readability and plain English

The accessibility guidelines state that: “when text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available” (success criterion 3.1.5: reading level, AAA standard).

Meeting this standard will make your publications more accessible to people with cognitive impairments and learning disabilities.

The guidelines also point out:

“Difficult or complex text may be appropriate for most members of the intended audience (that is, most of the people for whom the content has been created). But there are people with disabilities, including reading disabilities, even among highly educated users with specialized knowledge of the subject matter.”

Furthermore, expert users prefer simple language because it allows them to understand information as quickly as possible.


Tools to check readability

If your content does not contain any sensitive unpublished material, paste it into the online Hemingway App. It will give you a grade level readability score. Aim for grade 9 or lower.

If you cannot use the Hemingway App, then use the readability tools on Microsoft Word. This will give you a ‘Flesch-Kincaid Grade Level’. How to find your readability score on Word.

We think the Hemingway App is more helpful than Word so we recommend using this if you can.


We recommend avoiding symbols whenever you can.

This is because:

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

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

Pointers for written content:

  • Avoid the ampersand symbol, write out ‘and’ instead.
  • If possible, replace a forward slash symbol with the word ‘or’.
    • Note: if a slash is needed, there should be no space either side of it.
  • Do not use dashes to indicate a span of time or range of monetary amounts, use ‘to’ instead.
    • For example, write ‘£36,000 to £40,000’ instead of ‘£36,00 – £40,000’.
  • If you include footnotes in your publication, avoid using symbols such as an asterisk to label them – numbers or letters hyperlinked to the footnote are preferable.

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

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

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

Please also see our guidance on ‘Using symbols and shorthand in tables’.

Back to top of page

Making charts accessible

Chart content

When making your charts we recommend you follow our data visualisation guidance. Please be aware that this guidance has not yet been updated regarding the accessibility guidelines but we will be doing this soon.

The ONS guidance on data visualisation is very similar and should be followed by staff within ONS.

We are considering the development of an accessible colour palette to be used in statistical publications across the GSS. If this is something you would be interested in, please let us know by emailing

HTML charts

If the website you publish on has the functionality to build charts with HTML code and the functionality available is known to meet accessibility standards, you should use this.

If you publish on GOV.UK you can only create horizontal bar charts in HTML at the moment. See examples of the bar charts you can create on GOV.UK.

If you work for the Office for National Statistics your options for HTML charts are much wider.

If you cannot publish charts in HTML you will have to upload your chart as an image.

Charts presented as images

You can include some text – but not too much

The accessibility guidelines state that images of text should be avoided except for some limited circumstances (success criterion 1.4.5 images of text, level AA).

When it comes to text on images of charts, you can have some text in the image, such as axis labels and annotations (remember to use a sans serif font). But you should avoid adding any other text into the image such as headings or information about sources – this text should go in the body of the page.

Use chart headings correctly

The chart should have a title in the body text – ONS advises to have a descriptive title followed by a more formal statistical title.

The more formal statistical title (also sometimes called ‘metadata’) may have traditionally had ‘Figure n’ at the start to denote which number chart it is in the report. GDS no longer advise this for charts published on GOV.UK but ONS still advise it for their website.

These headings should follow the correct heading tagging structure which will depend on where a chart sits in a report. Remember, first level subheadings should be tagged as H2, second level as H3 and so on.

Use the Scalable Vector Graphic (SVG) format

Using the SVG format is not explicitly mentioned in the accessibility guidelines but they should be considered the most accessible option for images of charts. Unlike bitmap file types such as JPG or PNG, SVGs retain the same quality no matter what screen resolution or size they are viewed at. This means a user can zoom in and out and the image retains its quality – this adaptability makes it a more accessible format. Example of a chart image in an SVG, JPEG and PNG format.

GOV.UK allows this format but some websites may not. SVGs are also a relatively new format. If you work with a publishing team, talk to them about using SVGs and what formats they prefer you to supply images in.

There have been occasional issues with internet browsers not displaying SVG images. But the benefits of SVGs outweigh these issues, which happen rarely. We recommend that you check if people in your department can view the images.

Creating SVG files

To create an SVG, the tool you use to create graphs and charts must have a ‘save as SVG’ or ‘export as SVG’ option. Changing a PNG or JPEG file into an SVG does not make it scalable – it must be done from the source file.

There are several free tools you can use to create SVG files:

If none of these are suitable, your department may already be using a paid tool which can create SVGs. Some examples include:

  • Adobe Illustrator
  • Affinity Designer
  • Visio Professional
  • InDesign
  • PowerPoint (newer versions only)
  • Sketch

If you have an older version of PowerPoint then you should be able to export a PowerPoint slide in an EMF format and then convert this to SVG using an online file converter tool. However, this probably is not a suitable solution if you are working with pre-release data.

If you cannot use an SVG image then a JPEG or PNG image will do as a second best option.

If you want to know more, this blog post sums up the differences between image formats.

Supply alternative text

Alternative text refers to any text that describes non-text content. It is needed so that people with visual or certain cognitive impairments can understand the content communicated by images.

The accessibility guidelines state that “all non-text content that is presented to the user has a text alternative that serves the equivalent purpose” (success criterion 1.1.1 non-text content, level A).

Alternative text can be given through the ‘alt attribute’ which means it lives in the HTML code of the page, or it can be in the text displayed on a page (called ‘body text’). It should only be in one of these places, not both.

It should aim to give a disabled user as close to the same experience as a user who is not disabled.

It should not be in a caption – screen readers do not always pick up on captions.

Alternative text for charts should:

  • describe the important take-away message the chart is meant to deliver
  • not be a literal description of the chart
  • not outline every data point shown

If given through the alt attribute, the alternative text:

  • is displayed if the image file is not loaded or if a user has chosen not to view images
  • can be read by search engine
  • should be ‘null attribute’ (e.g. alt=””) if the image is just decorative or if you want to put the alternative text in the body text – this is automatically built in on GOV.UK if you leave the alt text field blank
  • should always be present – even if it is just alt=””
  • should be succinct – if it is too long it increases the time it takes for a screen reader to read the page and makes it difficult for the user to understand the significance of the images
  • should not be repeated in the image caption or body text
  • should not use phrases like ‘image of…’ or ‘graphic of…’ – generally, it will be clear that the content is an image
  • if it is connected to an image of a chart it should use phrases that describe the type of chart it is referring to, for example “a line chart showing ….”
Note on the alt attribute:

If you publish on GOV.UK you should not provide the alternative text in the alt attribute which is automatically set to ‘null attribute’ when you leave the alt text field blank. You must instead provide it in the body text of the page. The Government Digital Service prefer this approach as it allows all users to access the alternative text. Text in the alt attribute is generally only easily available to screen reader users.

If you work at ONS, they do allow (and advise) for alternative text to go in the alt attribute – you should follow ONS guidance for alt text.

Provide the name of the data source

Text stating the source for the data used to create a chart should be presented directly after every chart image.

This information should enable the user to find the data presented in the chart. It should not be as simple as ‘Source: Department for Work and Pensions’.

This text should be in the body text of the page and not part of the chart image.

This is not mentioned explicitly in the accessibility guidelines, but it is best practice when displaying charts. It is important for accessibility that it goes in the body text of the page and not inside the image.

Provide the data behind the chart in an accessible format

Providing the data behind a chart image is not explicitly mentioned in the accessibility regulations. But it is related to the regulation that states: “all non-text content that is presented to the user has a text alternative that serves the equivalent purpose”.

If you think a non-disabled user will just get a message from the chart, this can be given through alternative text and you do not necessarily need to provide the data directly after the chart image.

But, if you think a non-disabled user will use the chart image to investigate the data then you should provide an accessible version of the specific data used in the chart, directly after the chart image. This can be a HTML table of the data or an accessible data download.

In general, supplying the specific data used in a chart is considered best practice in terms of presentation and dissemination. The Office for National Statistics aim to do this for every chart on the ONS website. We are aware this may not be possible on all websites and that even if it is possible it may be very resource intensive to create this specific data. But, if you can do it you should do it.

If you publish on GOV.UK, depending on the template you use it may not be possible to link to a data download file underneath a chart. However, statistical producers at the Office for Standards in Education, Children’s Services and Skills (Ofsted) have found a workaround – they have been linking to a zip file of datasets for each chart.

The format you supply data in should be based on user research. More information on formats for data downloads can be found in the ‘Document formats’ section of this guidance.


What a chart presented as an image needs to have to be accessible:

  • Accessible colours and fonts (see our data visualisation guidance)
  • A title in the body text – remember any headings should follow the correct heading tagging structure.
  • Alternative text describing the message of the chart – this can be in the alt attribute or in the body text.
  • An accessible data download or HTML table of the specific data used in the chart if you think a non-disabled user would use the chart to investigate the data.

It is best practice to also have:

  • The name of the data source in the body text directly underneath the chart
  • An SVG image of the chart
Back to top of page

Making tables accessible

As analysts we publish three broad types of table:

  • demonstration tables that present important data within a report
  • reference tables which are provided alongside a report for users who need detailed data
  • machine readable datasets which are tables formatted to be read by machines

Demonstration tables

We have guidance for demonstration tables in our data visualisation guidance – but please be aware this has not yet been updated to reflect accessibility best practice.

If the website you publish on can create tables in HTML you should publish your tables in HTML format. For example, tables can be created in HTML on GOV.UK.

Converting a table created in Word or Excel to a table in ‘Markdown‘ can be tricky – this online markdown conversion tool may help (but be careful about using it with unpublished data). GDS have also provided guidance on the markdown to use when creating HTML tables to go on GOV.UK.

GDS have guidance on when to use HTML demonstration tables and how to ensure they are accessible.

Improving your understanding of how screen readers deal with HTML demonstration tables may also help you.

If you cannot publish tables in HTML you should publish them in a spreadsheet document. Images of tables should be avoided as images of text are only allowed in specific circumstances (success criterion 1.4.5 images of text, level AA).

Reference tables

If reference tables are published in spreadsheet documents, they need to be made accessible.

Our guidance on Releasing statistics in spreadsheets has in-depth advice on how to publish accessible spreadsheet documents.

Publishing alternative versions of the same document

If your current spreadsheet document does not meet the accessibility guidelines but you feel that it does assist your users, you can publish two versions of the same document. One that meets the accessibility guidelines and one that does not.

Back to top of page

Making other types of visual content accessible

If there are other types of visual content you need to make accessible but are not sure how, please let us know by emailing

You can also look at GDS guidance on other types of visual content such as diagrams and infographics.

Back to top of page

Document formats

Document formats should be the last resort for reports

PDF and other document formats are a last resort for any new text based publications like statistical reports. Wherever possible publications like this should be made available in HTML.

Reasons for this include:

  • document formats will never be as accessible as HTML content
  • search engines cannot look inside document formats – making content harder to find
  • document formats are harder to keep up to date than webpages because the editing process takes longer and sometimes the source copy of a PDF gets lost
  • it can be difficult for users to tell if a PDF is out of date as search engines often take users directly to a PDF – when this happens it is not easy to find out if it is the latest version

Read more about why website content should be published in HTML and not PDF.

Be aware that GDS no longer allow PDFs to be published on GOV.UK unless an accessible HTML or open document version is published alongside it.

Open formats

If you do publish documents you should publish them in an open format.

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

Files published in Microsoft Word or Excel format are not open because they rely on users having access to specific software.

Open formats for Microsoft Excel files:

  • Comma-Separated Values (CSV)

If your users want machine readable datasets you should provide them in a CSV format (or, ideally, through an Application Programming Interface (API)).

Files meant solely for machine consumption are out of scope of the accessibility regulations. This means they do not have to meet the accessibility regulations because they are not meant for users to read themselves.

If you publish a CSV file and intend for users to open, read and analyse the content themselves you need to make sure it meets the accessibility regulations. This can be more complicated than you might think. CSV files only allow one tab per spreadsheet and strip out almost all formatting. They do not provide the assistance certain types of formatting can provide, such as a clearly tagged header row and the ability to mark-up a table so a screen reader can understand it.

  • Open Document Spreadsheet (ODS)

These are very similar to Excel spreadsheets. ODS files allow more than one tab and formatting tools can be used to make the content accessible.

However, we understand it may not be straightforward to open ODS formats on older iPhones. In comparison, it is straightforward to open Excel spreadsheets.

Ideally you should supply data in multiple formats. But if this is not always possible, finding out what format your users need the most is the best approach.

Open formats for Microsoft Word files:

  • Open Document Text (ODT)

These text files will open on Word if you have that software but you do not need it to be able to open them. They will keep some Word formatting that makes content more accessible, for example bullet points and table formatting.

  • PDF

PDFs are a common way to present a text-based document online. They open in an internet browser and can be made to meet the accessibility guidelines.

However, making PDFs accessible can be quite complex and they are not the best option for accessibility. As mentioned, GDS no longer allow PDFs to be published on GOV.UK unless an accessible HTML or open document version is published alongside it.

The ODT format is more accessible than PDF because ODT files can be opened in software that allows the user to make changes to suit them. For example, users can change the size of the text and the colours used in images or charts.

However, we understand there may be some issues with the ODT format in some circumstances, you may want to check with your publishing colleagues or speak to your users for more information.

Back to top of page

Making document formats accessible

Sometimes publishing documents is unavoidable. In this section we have guidance on how to make document formats accessible. The steps you will need to take will depend on the format of your source document.

Making PDFs accessible

Ideally you will have the source document for your PDF. This will often be a Microsoft Word document. If you have this, you should take steps to make the source document accessible before saving it as a new PDF document.

If you do not have access to the source document you will need access to Adobe Acrobat software that allows you to make edits to the PDF document itself.

You will need to make sure the written and visual content is accessible by following the guidance in previous sections.

You will also need to ensure all content is tagged correctly so the structure can be understood.

Depending on your version of Adobe Acrobat you may also have access to the built-in accessibility checker. This can be used to check accessibility and will direct you to online tutorials about how to make edits to fix any accessibility issues it finds. However, the accessibility checker will not necessarily find all accessibility issues, think of it like a spelling and grammar check.

Making PDFs accessible is not always easy and if you publish on GOV.UK you should also be aware that GDS no longer allow PDFs to be published unless an accessible HTML or open document version is published alongside it.

Email if you are struggling with a PDF of a statistical or analytical publication that you need to make accessible and we will see what help we can offer.

Making Microsoft Word and Excel documents accessible


Strip out any content that is not necessary. Think about your document as if it is webpage on the website you are publishing on. Do not use lots of colourful diagrams and logos unless they are strictly necessary.


Properly structuring your content is important in order to meet success criterion 1.3.1 info and relationships, level A

If using Word:

  • use Word’s ‘styles’ tool to create a hierarchy of headings – the title of the document should be ‘heading 1’, first level subheadings should be ‘heading 2’ and so on (Worcestershire County Council have a good video that shows you how to tag headings in Word)
  • all text should be in a sans serif font (such as Arial or Calibri)
  • all text should have the ‘automatic’ colour selected (except for hyperlinks which take on the default blue colour)
    • this will mean editing the colour of headings after you tag them
    • using the ‘automatic’ colour is important as some users will need specific settings for colour contrast – when you select a specific colour, these settings do not get activated.
  • use the bullet point tool in Word to create lists
  • use the ‘insert table’ tool to create tables

It it also best practice to avoid justifying text (i.e. aligning it to both the left and the right margins). You should also ensure line spacing is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

Structuring content in Excel is a bit more complicated. See our ‘Releasing statistics in spreadsheets’ guidance.

Written content

The written content should follow the advice outlined in the ‘Making written content accessible’ section.

Set the language

Go to ‘File’ and then ‘Options’ and then ‘Language’. Make sure the document has the correct language(s) selected (success criterion 3.1.1 language of page (level A)).

File name

File names should:

  • 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 including spaces
  • not include acronyms – put these in the document information as keywords or tags
  • be entirely in 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-how-to-make-documents accessible’ is a more sensible file name than ‘access-guid-final-draft-Han-edit3’)

There is not a specific success criterion in the accessibility guidelines for file names but it comes under ensuring content is understandable by making it readable and predictable (guidelines 3.1 and 3.2).

Provide information about the document

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

Title – this should replicate the title on the front cover – do not use dashes or underscores here.

Author – generally this should be the organisation that published the document.

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. They also help with finding your document internally.

The information in the title field is required by the accessibility regulations (success criterion 2.4.2 page titled). It is best practice to also fill in the author and keyword fields.

Checker tool

Newer versions of Microsoft Word and Excel have a built-in accessibility checker. If you have this, run an accessibility check and correct any issues. It can be found under the ‘Review’ ribbon.

Note: although the accessibility checker is a useful tool, it may not pick up all issues such as links without specific descriptions. Treat it like a spelling and grammar check.


It is best to avoid images in Excel documents. This is not mentioned specifically in the accessibility regulations but because Excel documents are more difficult to navigate in general, images can complicate this further.

Images in Word documents should have appropriate alt text in the properties of the image, unless they are only decorative, in which case they should have two double quotation marks (“”) in this field. Read more about alternative text in the ‘Making charts accessible’ section.


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

To ensure you meet the success criterions relating to tables, make sure:

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

You can also add alternative text in the table properties, but this is not strictly necessary for tables and it will be removed if you save the document in Open Document Text (ODT) format.

When making tables in Excel documents see our guidance on Releasing statistics in spreadsheets.

Saving or exporting

When it comes to text documents remember that ODT files are better than PDFs in terms of accessibility because they can be opened in software that allows the user to adjust the content to their needs.

If you have to save a document in a PDF format please follow the following steps:

  1. Go to ‘Save as’
  2. Choose PDF in the ‘Save As’ dialog box
  3. The dialog box will adapt slightly – you should see an ‘Options’ button – click it and make sure the following checkboxes are selected:
    • Create bookmarks using headings
    • Document properties
    • Document structure tags for accessibility
  4. Click ‘Save’

If you work with a publishing team you might want to check with them about whether they want you to save or ‘export’ your document to PDF. The important thing is to ensure the checkboxes outlined above are ticked.

Checking PDFs online

If you have a PDF of previously published material and you would like to check if it is accessible you can use an online accessibility checker. But, remember, just like the accessibility checkers built into the newer versions of Word, Excel and Adobe Acrobat, these checkers will not pick up on everything. Treat them like a spelling and grammar check.

Linking to documents hosted on other websites

It is best practice to always link to accessible content when you can.

If you have control over the content you are linking to you have an obligation to make it accessible under the regulations.

If you do not have control over the content you want to link to, you can link to content that does not meet the accessibility regulations if necessary.

Guidance from the Government Digital Service (GDS)

GDS have also published guidance on Publishing accessible documents that you may find useful.

They have also shared a video about publishing accessible documents.

Back to top of page

Making social media content accessible

Creating accessible content for social media will help you reach more people.

Furthermore, publishing inaccessible content on social media platforms could be breaching legislation such as the Public Sector Equality Duty (part of the Equality Act 2010).

Guidance to help you ensure your social media content is accessible:

Back to top of page

Tools to check accessibility

  • WAVE accessibility tool – this is a Google chrome extension
  • High contrast – Google chrome extension to help you check your site using different types of contrast options to make sure content is still readable/visible.
  • NVDA – free screen reader software which can be used to test the accessibility of websites and documents

For automated testing you can use a range of tools, including:

See the GDS accessibility team’s audit of the most used accessibility tools if you’re not sure which tools to use.

You can also perform manual checks:

Back to top of page

Accessibility help

Help from the Government Digital Service (GDS)

GDS has set up an accessibility community.

You might be interested in this community if your work involves:

  • writing content or code
  • designing the user experience
  • doing user research
  • managing a product or service

You can also join if you want to learn more about accessibility, or if you do not want to tackle accessibility issues on your own.

You do not have to be in an accessibility-related role to join, but you must be working in or with government. Most people in the group are not accessibility specialists.

Basecamp board for analysts and statisticians

We have also set up a board called ‘Accessibility for statistics‘ on the Basecamp website. You can post questions, share knowledge and review past questions and answers on the message board.

Back to top of page

Related links

Legislation and guidelines

Guidance from the Government Digital Service (GDS)

Help with converting to HTML

Help with spreadsheets

Help with images

Help with colours

Other useful links

Still have a question?

Try the ‘Accessibility for statistics’ message board on Basecamp.

Back to top of page
  • If you would like us to get in touch with you then please leave your contact details or email directly.
  • This field is for validation purposes and should be left unchanged.