In the UK, almost 1 in 5 people have a disability of some kind. 

Many more have temporary or situational disabilities, like an illness or injury. 

Recent regulations mean that, from next year, every new public sector website and app will need to meet specific accessibility standards

Existing websites will have until September 2020 to comply, and apps until June 2021.

We’ve published guidance setting out accessibility standards for NHS digital services for the public. 

It grew out of work we've been doing to improve the accessibility of the NHS website, but we hope it'll be used by digital teams across the NHS and inspire the broader public sector.

When we launched our front end library and prototyping tools in February 2019, all of the code and patterns were tested for accessibility, and we developed some initial guidance around accessibility.

We’ve now updated that guidance to be more comprehensive, and more useful, to people working in digital delivery teams. 

It’s advice that we think everyone needs to know, whether you’re building a service, or commissioning one. 

It sets out what should be done and, importantly, how to do it on a practical level.

We also plan to publish more things that will help people embed accessibility thinking in their practice – for example, checklists and templates, particularly for testers. 

We’ll also be building an Accessibility Lab in our office in Leeds and a ‘roaming suitcase’ of accessibility equipment for London and the other regions.

So, how have we assembled our accessibility pages in the service manual? 

Our core guidance opens with three topics for everyone:

The NHS digital service manual team is a multi-disciplinary team. 

Not all teams across the NHS will have specialist roles but people involved in projects may be involved in multiple types of activities. 

For example, an interaction designer may also be involved in conducting user research. 

We’ve therefore labelled the guidance by activity rather than roles.

  • Product and delivery: including the questions product or delivery managers need to be asking
  • User research: from identifying target groups and accessibility challenges to including users with access needs in research and practicalities like making your research sessions more accessible on the day
  • Content: how to write effective, clear content as well as headings, good link names, handling images in content and making multimedia accessible
  • Design: it includes, for example, colour contrast, designing new components (only after you've tested existing ones) and handling errors in forms
  • Development: including information on how to make your service accessible for those who can’t use a mouse or trackpad and rely on keyboards or joysticks
  • Testing: different kinds of testing (user research, manual and automated) and the wide range of things that may need checking