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 online 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 analysis and statistics, please see our guidance on “Accessibility legislation: what you need to know“.
What this guidance covers
This guidance aims to help producers of government statistics and analysis meet the UK accessibility regulations for public sector websites.
It does not cover absolutely everything you could do to make content accessible because assistive technology is constantly adapting and research into different barriers disabled people face is increasing. We will update this guidance frequently to reflect any new findings.
The guidance covers content within analytical publications. It 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 GDS has guidance for publishing on GOV.UK and 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. We also try to make it clear when the guidance is directly linked to the accessibility regulations required by law or simply best practice.
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.
But, it is worth noting anything that improves the consistency of written content 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) state 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 giving 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 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 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.
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.
Be consistent in presentation of bullet points. We recommend the GDS style guide advice for bullet points.
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’.
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.
Examples of good practice:
12 March 2014.
Monday 3 March 2014.
Be consistent in how you embed email addresses.
We recommend you write email addresses in full, in lowercase (even if they are names) and as active links so the email address link automatically opens the default email provider. Do not include any other words in the link text.
Example of good practice:
Contact email@example.com 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.
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.
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, the 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’re publishing directly onto a webpage or creating a document for publication. There is more on tagging headings in document formats in the ‘Accessible formats’ section of this guidance.
Hyperlinks (links to other webpages)
Hyperlink text should be a specific description of the destination page, not just ‘blog post’ or ‘report’ for example. It should never be directional text like ‘click here’.
Do not use the URL of a webpage as the hyperlink text, unless it is very short (e.g. www.unsplash.com). Long URLs get read out by a screen reader in full which can be very time consuming and annoying. Also, in most circumstances they do not describe the destination page.
We advise that links 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)‘.
If you are linking to a 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)‘.
If you consider how people without sight impairments normally use webpages they scan to find what they want, and often what they want is a link. Screen readers can be programmed to read out a list of links on a page to give visually impaired people the same sort of experience. When link text is not specific, the links will be difficult to tell apart so the person cannot easily find a link they may be interested in.
When you write links, 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 the same non-specific link text: ‘Find out more’.
Link text should be underlined by default. If it is not underlined you have to consider colour contrast with surrounding text and a “visual cue” that appears on mouse hover and keyboard focus.
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.
In general however, the ONS style guide has more specific guidance on writing about numbers in statistical publications so we would recommend using that.
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.
Use plain English.
Keep sentences and paragraphs short.
Do not use figures of speech.
Replace complex words with simple alternatives – the plain English campaign has an A to Z of alternative words.
Avoid using these words (a list from the Government Digital Service).
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.
Some screen reader software will not recognise certain symbols and some screen reader users may have changed their settings to ignore symbols to avoid auditory clutter. Therefore, we recommend avoiding the use of symbols whenever you can.
- Write out ‘and’ at all times. Do not use an ampersand symbol.
- If a forward slash symbol is used to show ‘or’, replace it with the word ‘or’. 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’ for a salary band instead of ‘£36,00 – £40,000’.
- If you have to include footnotes in your publication, avoid using symbols such as an asterisk to label them – hyperlinked numbers or letters are preferable, although in general we advise to avoid the use of footnotes altogether.
Some symbols are needed and generally understood by screen readers. For example on the Government Statistical Service(GSS) website we use all the standard punctuation symbols and these symbols: %, £, $,°, @.
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 when using their default settings. But, as mentioned, some users may have changed their settings from the default so in general it is best to use words instead of symbols wherever possible.
Making charts accessible
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 firstname.lastname@example.org.
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. However, GDS no longer advise this for charts published on GOV.UK.
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
- PowerPoint (newer versions only)
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 succinctly 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 around 125 characters in length – 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.
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 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 ‘Accessible 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
Making tables accessible
As analysts we publish three broad types of tables:
- 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
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).
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.
Saving a spreadsheet document
You will need to add some information to your document to ensure it meets the accessibility regulations.
You should also take care with file names.
More information on both these aspects can be found in the ‘Accessible formats’ section.
Publishing alternative versions of the same document
If your current table formatting 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.
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 email@example.com.
You can also look at GDS guidance on other types of visual content such as diagrams and infographics.
Document formats should be the last resort
PDF and other document formats are a last resort for any new publications. Wherever possible publications 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 editable 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.
Whenever possible you should publish documents 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.
Microsoft Excel files can be published as:
- Comma-Separated Values (CSV) files
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) files
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.
Microsoft Word files can be published as:
- Open Document Text (ODT) files
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.
PDFs are a common way to present a text-based document online. They open in an internet browser and can be made accessible.
However, making PDFs accessible can be quite complex and they are not the best option for accessibility. 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.
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 firstname.lastname@example.org if you are struggling with a PDF of a statistical 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 the 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 colour instead of automatic these settings do not get activated when a user opens a document.
- 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) and to 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.
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).
File names should:
- be unique, e.g. 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 but optional with regards to accessibility regulations.
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 the 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:
- Go to ‘Save as’
- Choose PDF in the ‘Save As’ dialog box
- 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
- 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.
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:
- Planning, creating and publishing accessible social media campaigns – guidance from the Government Communication Service
- Making your social media accessible – guidance from the Royal National Institute of Blind People (RNIB)
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:
Help with accessibility
The Government Digital Service (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.
Legislation and guidelines
- Accessibility legislation
- Web Content Accessibility Guidelines (WCAG) 2.1
- Our own guidance on the accessibility legislation
Guidance from the Government Digital Service (GDS)
- GDS version of WCAG A and AA guidelines
- GDS guidance on understanding WCAG 2.1
- GDS guidance on understanding accessibility requirements for public sector bodies
- GDS guidance on making things accessible and inclusive
- GDS guidance on content design: planning, writing and managing content
- GDS guidance on publishing accessible documents
- GDS guidance on making your service accessible
- GDS guidance on testing for accessibility
- GDS guidance on how to make tables accessible on GOV.UK
- GDS guidance on making visual content accessible on GOV.UK
- GDS guidance on using Markdown to format content on GOV.UK
- GDS library of HTML elements designed to be accessible
- Video about creating accessible online documents
Help with converting to HTML
Help with spreadsheets
- Our own ‘Releasing statistics in spreadsheets’ guidance
- Our checklist for making spreadsheets accessible
- Microsoft guidance on making Excel spreadsheets accessible
- Guidance on making spreadsheets accessible from Michigan State University
- Royal National Institute of Blind People (RNIB) guidance on creating accessible Excel spreadsheets (DOCX, 192KB)
Help with images
- Examples of tables and charts you can publish on GOV.UK
- Accessibility guidance for complex images (like charts)
- Guidance on alternative text from WebAIM
- Guidance on images from WebAIM
- Alt text decision tree
Help with colours
- Colour contrast checker recommended by GDS
- WebAIM colour contrast checker
- WebAIM link contrast checker
- Colour palette guidance
Other useful links
- Guidance on writing good hyperlinks
- PDF accessibility checker
- GDS style guide
- Accessibility in PowerBI
You can also contact us with your accessibility queries, either via the feedback box or by emailing email@example.com.