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

Text and hyperlinks

  • 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.


When creating hyperlinks, the text containing the link should be a specific description of the destination page. Ideally, links should be placed near the end of a sentence so that users can take action immediately, rather than having to remember to go back.

There is more information about accessibility within GOV.UK content if you are interested.

A further explanation is provided in the full terms and conditions.

Assistive technologies separate out links, so each one should be easy to identify and clearly tell the user where the link will take them.

accessibility within GOV.UK content

full terms and conditions

If a hyperlink will involve downloading a file rather than going to another web page, users should be informed what type of file they are about to download and its size.

In July we published a new user guide for population statistics (PDF, 100KB)

Quotation marks are not needed around a hyperlink.

Alt text

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

Alt text should be around 125 characters (15 to 20 words), be no more than one sentence and include:

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

Avoid using a literal description of the image or chart and instead focus on what point it is making.

Alt text can duplicate part of the descriptive chart title but should not repeat content in the main text. This causes “auditory clutter” for screen reader users where information may be repeated several times. Screen readers will read out the chart title and subtitle, so do not worry about fitting all of this information into the alt text as well.

When describing this chart, the alt text could read: 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.


  • 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 accessible tools and so they are not likely to meet the required 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 may need to 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.


  • Use a simple table structure with clear headings and subheadings.
  • Avoid splitting or merging cells.
  • Avoid using colour to convey information: where you have to use colour, make sure the contrast meets WCAG AA standard.
  • Use the built-in accessibility checker in Excel to identify and fix any accessibility issues.
  • If publishing tables in PDF format or HTML, make sure a downloadable XLS version of the data is available and clearly signposted.

The Government Statistical Service (GSS) provides detailed guidance on releasing statistics in spreadsheets.

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