What is accessibility?

Website accessibility describes whether a website can be used by people of all abilities. Good accessibility makes it simple for every user to find, use and understand content. 

UK Government Accessibility Regulations mean that all public sector organisations have a legal duty to make their websites accessible for everyone, including those with disabilities. 

If you fail to meet accessibility standards you could be breaking the Equality Act 2010. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 became UK law in September 2018, with the compliance deadline for making public sector websites accessible to everyone being 23 September 2020.

Publishing web content in HTML makes it accessible to as many people as possible across all devices. It also allows for users who need to change the way they view the web page, for example, changing the size of the text or colour contrast.

A good measure of whether web content is accessible is to make sure users can:

  • perceive and understand it, whether through sight, sound or touch
  • operate using screen readers, voice activation software, high contrast, and other tools with ease
  • understand the content written in plain English
  • access the content with all browsers and devices

Accessible text

  • Write all content in plain English, and explain all abbreviations and jargon.
  • Include a summary or bullet points of the main information at the beginning of the content.
  • Try to make paragraphs no more than two or three sentences, breaking up the text into short chunks.
  • Use headings and subheadings to break up sections of text and create structure.
  • Use bullet points for all lists of three things or more.

It is important to write simply and consider the reading order of your content so that it flows naturally. If you are unsure, test your content by asking someone to read through it to make sure the language and order makes sense.

Formatting of text

Avoid using italics or bold, underlining text and overuse of capital letters, as the text could be mistaken for a heading and large amounts can be hard to read for users with visual impairments. Instead, create emphasis through what you write.

Numbered lists

Use numbered lists when describing a sequence that must appear in a specific order, such as a set of instructions, a series of sequential questions or a top 10 list. These lists follow a similar style to bulleted lists, but:

  • must be a complete, concise single sentence
  • have an initial capital letter in the first word
  • end with a full stop or question mark

Remedial actions to take for quality assurance:

  1. Clarify contact details for Consumer Intelligence.
  2. Seek further quality assurance information from Consumer Intelligence.
  3. Establish a dedicated contact for Moneyfact and keep current.
  4. Seek further detail of Moneyfact’s quality assurance procedures.

Directional text

Do not use directional text, such as “click here” or “the list below”, as this could be misleading for people using various tools to browse the website.


Hyperlinked text allows users to navigate to another page or file for additional information. If the relevant information exists elsewhere on the ONS site or is available from another organisation, link to it to avoid duplication. Only link to the most useful information as too many hyperlinks are distracting to users.

It is important that users can easily identify all hyperlinks and can see where the link will take them. Where appropriate, use the title of the publication you are linking to as hyperlink text. Hyperlinks should be accessible for all users.

Link text should:

  • clearly describe the topic or purpose of the destination page
  • be as concise as possible without losing meaning
  • make sense as part of a sentence, and as text on its own
  • say if the link opens in a new window
  • be at the end of a sentence where possible

Compare the GDP figures with previous preliminary GDP estimates.

More information on the uses of data is available in the Births QMI.

Read our terms and conditions.

Link text should not:

  • use generic words such as “click here” or “this article”
  • use full URLs
  • have quotation marks
  • be used more than once in each section
  • use different text for the same destination

Click here to compare the GDP figures with previous preliminary estimates.

The Births QMI contains information on the uses of data and is available on the ONS website

Read our terms and conditions at https://www.ons.gov.uk/help/termsandconditions.

Linking to files and attachments

Where possible, always link to a web page. If there is no alternative to linking to a file download, make it clear what file type and size it is.

In August, we published a user guide to the Labour Force Survey (LFS) questionnaire (PDF, 3.4MB)

When linking to an ONS release, try to include the source, title, type, and data range of the release.

For more insight into these developments, you can view the data in our Public sector finances, UK: January 2022 bulletin.

Alt text

All charts and images must have alt text, or alternative text, to summarise what they are and show for users who cannot see them. Screen readers read this information out for people with visual disabilities. Alt text can also be used to describe what should be on the page if the web browser fails to load the images.  

Alt text should include: 

  • the chart type (for example, bar chart, line chart or pie chart) 
  • the type of data in the chart (for example, marriage rates, level of GDP, or amount of weekly hours worked)
  • a summary of the main trend of the chart 

Alt text should:  

  • be around 125 characters (15 to 20 words) – it can be longer if needed, but if it is too detailed then include some content in the main text instead  
  • be no more than one sentence 
  • include a full stop at the end 
  • include any abbreviations written out in full  

If your chart describes the trend

Your chart title should usually be a description of the data’s trend or highlight a main story. If this is the case, you can duplicate part of the descriptive chart title in the alt text. 

When describing this chart, the alt text could read: A line chart showing the amount of weekly hours worked is still low but showing signs of recovery.

Example of a line chart showing the amount of weekly hours worked is still low but showing signs of recovery.
You can read more about our chart title guidance.

If your chart title does not describe the trend 

If you do not have a descriptive chart title, you should first consider if your title could describe the data’s trend or highlight a main story. If it cannot, your alt text should still describe the trend where possible.  

Your alt text summary should not: 

  • use a literal description of the chart – instead, focus on the point it is making 
  • repeat content in the main text – this causes “auditory clutter” for screen reader users where information may be repeated 
  • repeat information from the subtitle as screen readers will read this out too  

If there is no data trend or story to highlight, you can use your chart’s title in the alt text even if it is not descriptive. 


  • All content in charts (such as axes, keys and other labels) must display horizontally and be easy to read.
  • Ensure axis labels are displayed in full and not cut off or abbreviated.
  • Write out abbreviations in full or clearly explain them in the footnotes.
  • Do not rely on colour alone to convey information: ensure there is a high enough colour contrast ratio between chart details and background colour.
  • If the axis includes dates, these must be consistently displayed for all charts in the release so that they are easy to follow.
  • The key must always display above the chart for easy reference.

An interactive HTML chart should always be used rather than an image of a chart. This ensures that all users are able to read it, including those with assistive technology such as screen readers. 

If charts cannot be produced in HTML, then SVG images are more accessible than other formats because they can be magnified.

When publishing graphs showing complex information, make sure that a clear text alternative is provided. For example, you could describe the trends in body text and have a table showing the most important data points.

You must also link to the raw data in a XLS or CSV file, or provide a way for users to request it.

Interactive charts will also adapt to the size of the screen being used to view the content, so they are more useful to users accessing the content on a mobile or tablet.

Chart titles should be descriptive and clearly explain what the data are showing.

Avoid using dual axis charts as they are often misleading and difficult to understand. Either use separated charts or a single axis chart which uses annotations to explain the trends.


  • Tables should only be used to present data, not lists of text.
  • Important information should be displayed first.
  • Abbreviations should be written out in full or clearly explained.
  • Column headings in tables should be clearly visible.
  • Decimal rounding should be consistent throughout the table.
  • Ensure there are no blank rows or columns.
  • Do not use any bold or italic formatting.
  • Numbers should be right-aligned, text should be left-aligned.

The size of a table can have a big impact on how easy it is for users to read and understand it. Consider whether the information can be better presented in the text as a bulleted list or split into headings and subheadings. 

An increasing amount of users view data on a mobile or tablet, so narrow tables are preferred to wide tables. As a guide, three to four columns can fit onto an average smartphone screen without too much scrolling.

Large tables containing a lot of data may be better presented as a dataset (downloadable spreadsheet).

The Government Digital Service (GDS) guidance on tables contains more information on how to make usable tables.

Images and maps

Images can be useful to illustrate a point, but they should not be used as a replacement for a clear text description.

When publishing charts as image files, the underlying data must be available as a download for users who cannot see the image.

Format and size

Images must be no more than 600 pixels wide but can be longer than 600 pixels. Always consider usability when determining the length of an image; it needs to be fully visible on-screen without too much scrolling.

Wherever possible, provide images in SVG format so that users can magnify the content.

Text in images

Do not use text in images. If it cannot be avoided, the same text must be explained as a long description nearby on the page or in the alt text. This is so that it can be changed into other forms such as braille, speech or symbols.


Logos should not be included. If they must be included to show a collaboration with another department or organisation, there must be accompanying text naming the organisation. Logo images do not need alt text as this would repeat the text.

Use of colour

Avoid using colour alone to convey meaning in an image, as users with visual disabilities can find it hard to distinguish between them. Using red and green together is a common example as many people are unable to tell these colours apart. If you have to use colour to help explain something – check it with colour blindness software.

Interactive maps

Maps with multiple clickable areas should provide an explanation in the alt text or in the text nearby that gives an overall context to the meaning of the map.

Video, audio and interactive content

We do not currently support audio and visual content on the website.

This can present barriers for some users, but it can enhance accessibility for others. Some users may prefer to access data in a non-text-based format.

When presenting data in an interactive format, provide the data being used as a downloadable CSV or XLS file.

When using audio or video content, always provide a transcript and captions. If the content is also on a third-party website, provide it there if possible. For example, on YouTube you should provide a transcript in the comments section and an option to turn on closed captions. As well as being helpful for users with visual or hearing disabilities, it allows all users to download the information for offline use to read in their own time. 

When using video or audio content, avoid flashing lights and images, which can cause seizures, and keep distracting background noise to a minimum.


Before using a diagram (such as a process map, flowchart or illustration), consider whether the message can be communicated better through text or a table, as users often find them difficult to understand.

All diagrams must be created by Digital Publishing. Consider whether you can reduce the complexity of the thing you are trying to convey, and contact the Content Design team at the earliest opportunity. We can help you decide if a text or table alternative may be more suitable.

If there is a user need to provide a diagram instead of a text explanation, it must:

  • have a clear starting point
  • follow normal reading direction, from left to right and top to bottom
  • avoid having overlapping lines or arrows
  • use simple shapes
  • use black and white as a default: if you do need to use colour, make sure the contrast meets WCAG AA standard (use a colour contrast checker)
  • be created by the Design team in Digital Publishing

Diagrams must also follow the same guidance for using images, including as little text as possible.

There is further guidance on how to format your information in the Data visualisation section.

PDF and Word content

Do not publish PDF-only or Word-only content on the website. PDFs and Word documents are difficult to use with assistive technology and are unlikely to meet the accessibility standards required by law.

Research and Government Digital Service (GDS) guidance shows that users find PDFs more difficult to use than web pages. PDF files are less accessible than HTML pages, so should not be used without an HTML alternative.

If a PDF or Word file is necessary and it is not possible to provide an HTML alternative of the content, such as when publishing guidance for older surveys, make sure the documents are altered to meet accessibility standards.

Failing to make PDFs accessible could break the Equality Act 2010.

The PDF should have:

  • correctly tagged headings, text, bullet lists, tables and images so screen readers can understand the structure
  • a logical reading order for users navigating the document using the tab key on a keyboard
  • alternative (alt) text added to all images
  • bookmarks for all main headings in the navigation pane and the PDF file set to open this pane automatically
  • all content written in plain English following ONS house style conventions
  • a hierarchy of headings created using styles: “heading 1”, “heading 2” and so on (do not use bold, italics or all capitals)
  • all text in a sans serif font like Arial or Helvetica, with a minimum size of 12 points, left-aligned, and in single columns

If you are creating a PDF using Microsoft Word or PowerPoint, you can use the built-in accessibility checker to pick up issues that are affecting your document before you export it to PDF.

After creating your PDF, you should also use the accessibility checker in Adobe Acrobat Pro to check your PDF meets the necessary standards. If you do not have Acrobat Pro, you can request it via the Service Desk or speak to the ONS Graphic Design team to fix certain issues.

You should also check your PDF is accessible with a screen reader.

These checks should all be carried out and any accessibility issues resolved before the document is uploaded.

PDF titles and file names

Clear and useful titles and file names help users understand what a PDF document contains without having to open and read the entire document. Without a descriptive title or clear file name, users may need to spend time searching the document to decide whether the content is relevant.

PDF documents should have titles and file names that describe the topic or purpose of the page. They should be:

  • written in plain English and using house style
  • using terms and phrases that reflect the language of our users
  • as short as possible and no more than 31 characters
  • frontloaded (with the most important information first)
  • written in sentence case

They should not contain autogenerated sequences of letters or characters that provide little or no meaning.


As a good starting point for assessing the accessibility of your dataset, use the built-in accessibility checker in Excel to identify and fix any issues. However, do not rely on this check alone to make sure that your file can be used by everyone.

Alt text

Datasets should not include images, graphics, charts or embedded objects. Where this cannot be avoided, include alt text with all visuals to help users navigating the file with accessibility software understand the importance.


Users accessing your data with a screen reader are able to scan a list of hyperlinks in order to find what they are looking for. To make this as easy and useful as possible, make sure to use meaningful hyperlink text that provides accurate information about the link destination.


Do not use colour to convey meaning that is not shown another way, such as with a symbol. If there is a situation where you cannot avoid using colour, make sure the contrast meets WCAG AA standard and that the information is explained clearly elsewhere in the dataset.

Use black or dark grey for all text as the higher the level of contrast between the text and background, the more people can see and use the content. This is especially helpful for users with low vision.


Give each tab a unique name that clearly describes the information found in the worksheet and avoid using non-descript titles like “Sheet 1” as screen readers will read out tab names. 

Remove any blank tabs for easier navigation. 


Use clear column headings to provide context to the data and help users to navigate and understand the contents.

Users with dyslexia can find it difficult to read a lot of crowded text. It can be helpful to make the most of white space and extend the height or width of columns so that text sits comfortably and clearly within the cells. 


Most accessibility software will navigate an Excel file by reading the table header rows, so use a simple table structure with clear headings and subheadings. 

Screen readers keep track of their location in a table by counting table cells. Try not to: 

  • include blank cells, columns or rows 
  • nest tables within other tables
  • merge or split cells 

These things can be misleading to a screen reader. This type of formatting can cause it to lose count and cannot provide helpful information to the user.

Further guidance on how to format your datasets is available on the datasets page.

We are constantly improving based on research and best practice. Any significant changes to our guidance are available on the Updates page.