Skip to main content

Accessibility for digital services

It's a legal requirement for all public sector bodies to ensure that their websites and mobile applications are accessible. This is done by showing compliance to the 'AA' standard of the WCAG 2.1 guidelines. This document sets out the principles of accessibility and how to comply.

Why accessibility matters

Accessibility for web-based products means making sure that everyone can see and interact with content on your website or app. This means making sure it can be used by people with a wide range of different abilities. People can have a wide range of impairments, from the relatively minor to those with major impacts. 

Making your site accessible can be complicated. You can't foresee every accessibility need, but by following some principles, you can make sure the widest possible range of people can use your service.

For public sector bodies in the UK, including the NHS, it's a legal requirement under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Non public sector bodies are also obliged to make their websites accessible under the Equality Act 2010.

The most recognised standard for accessibility is the Web Content Accessibility Guidelines (WCAG - pronounced WiK-aGG) produced by the Web Accessibility Initiative of W3C, who set standards for the world wide web globally. This is a set of measurable standards which can be checked.

The current version of WCAG is 2.1, and there are three levels of compliance from 'A' (the lowest), to 'AA', and 'AAA' (the highest).

By law, public sector bodies must meet the 'AA' standard of the guidelines.


Principles of accessibility

Good web accessibility means using good quality code, and giving users as much control as possible. 

The four WCAG principles are:

  • perceivable - users must be able to perceive the content on the page, by seeing it, hearing it, or another method
  • operable - users must be able to use the content on the page, like forms, even if they don't have a mouse or screen
  • understandable - users must be able to understand the content and tools
  • robust - the content is compatible with the widest possible range of technologies and future technologies.

You need to consider how the site might work for users who don't have a common setup. For instance, users might not have a screen, relying on text-to-speech or braille output. This means that all text needs to be readable without a screen. A common mistake is including text as part of an image, which then cannot be seen by users of assistive technology.

Progressive enhancement

The best method for accessible, robust content, in almost all cases, is using progressive enhancement.

This means making sure that your page works using HTML5 only, and then improving that with Cascading Style Sheets (CSS), and if necessary making further improvements with Javascript.

Javascript is not natively accessible to all users, such as those with some braille computers. Requiring Javascript for the user to load a page means that some users cannot access it all. That would be a failure of 'perceivable' on the WCAG framework at 'A', and does not meet the legal minimum required standard.

To comply with the accessibility regulations, all services must:

  • have pages that load, with information that makes sense, even with Javascript disabled (even if that information is just to tell the user the alternative route to the same information or task)
  • give users without Javascript the ability to complete the same tasks as those with Javascript, within reason

Some features cannot be easily created without using Javascript, such as interactive charts, maps, or tools. In this case, you should consider:

  • ensuring that only the feature that requires Javascript uses it - not the rest of the page
  • if your choice of feature does genuinely require Javascript, or if a progressive enhancement build could achieve the same objective (even if it is harder to build)
  • if you can present a non-Javascript version for users without it, using server-side rendering - for example, an interactive graph could be displayed as a static SVG if the user does not have Javascript enabled
  • what alternative route you can give non-Javascript users, such as links to the data files used to render a chart or map

Well-designed Javascript can help with accessibility and usability of your site. Enhancements can include highlighting or making certain elements 'sticky'.

If you do use Javascript to improve the user experience for users without accessibility needs, users must be able to perform exactly the same tasks with Javascript turned off. If this is not the case, then you must complete and publish a disproportionate burden assessment, explaining why you cannot, or are not, making it fully accessible.


What services need to be accessible

All digital services produced by or for public sector bodies must comply, and meet the 'AA' standard of accessibility.

This includes:

  • websites and all their content
  • any software which uses the web browser as the interface
  • intranets
  • extranets
  • applications for mobile devices, such as phones or tablets

You’re legally responsible for your website meeting accessibility requirements, even if you have outsourced your website to a supplier.

Exceptions

Some content is exempt from the accessibility regulations - mostly older content.

The exemptions are:

  • pre-recorded audio and video published before 23 September 2020
  • live audio and video
  • heritage collections like scanned manuscripts
  • PDFs or other documents published before 23 September 2018 - unless users need them to use a service, for example a form that lets you request school meal preferences
  • maps - but you’ll need to provide essential information in an accessible format, like an address
  • third party content that’s under someone else’s control if you did not pay for it or develop it yourself - for example, social media ‘like’ buttons
  • content on intranets or extranets published before 23 September 2019 (unless you make a major revision after that date)
  • archived websites if they’re not needed for services your organisation provides and they are not updated

Disproportionate burden

Even if none of the exemptions apply, it may not be possible or appropriate to upgrade the accessibility of your digital service. In these cases, you must complete and publish a disproportionate burden assessment.

The basis of this is explained on the GOV.UK guidance for complying with accessibility requirements.

You should explain why you have decided that it would be too difficult or costly to make the service fully accessible.

Our page on conducting a disproportionate burden assessment gives more guidance.


Building new services

You must consider accessibility from the start, when building new services.

View our standards for web products as a starting point.

In your user stories, make sure that accessibility is included in the acceptance criteria.


Checking existing services

Existing services must also comply, unless one of the limited exemptions applies.

Check if your service is compliant, partially compliant, or non-compliant by conducting an audit.

We have a process for accessibility audits, which can be followed by any user with reasonable technical expertise. You can do this with your own team.

Find some of the most common failures by:

  • running your pages through the W3C validator - any failures here mean your page does not meet the 'A' standard
  • navigating your pages using a keyboard - if it's not clear what is selected, or you cannot easily navigate, the page fails at the 'A' standard
  • turning Javascript off in your browser - if you cannot load the page (or an accessible alternative), your page fails at the 'A' standard

If any of these causes a failure, you are likely to need detailed accessibility input.

You can also employ an agency to conduct these checks for you. If you do, you should make sure they:


Use of PDFs and office documents

PDFs and other office documents do not meet the same level of accessibility as well-designed web content. Public sector bodies, including the NHS, should not use PDFs or office documents to communicate information, except in a few very limited circumstances, as doing so is unlawful.

Find out why PDFs are not accessible and why web content should be used instead

Last edited: 22 September 2020 10:05 am