Why do we need to make our products accessible?

As part of the public sector, we are required by law to meet accessibility requirements for both internal and external users.

We also want to ensure all our users can access and use our products easily and without hindrance. This means that if an individual has an illness, impairment, or a disability, they will be able to use our products. We should prioritise making something accessible without alternative options, with an alternative option being a second resort, to ensure the user can obtain the same information. For example, you would not make text small assuming someone could use a magnifier.

An alternative route for someone with impaired vision would be to use a screen reader (software that lets a user navigate a website and ‘read out’ the content), braille display or screen magnifier. Or someone with motor difficulties might use a special mouse, speech recognition software or on-screen keyboard emulator. However, the content should first be prioritised as accessible.

Source - accessibility and the public sector

The Public Sector Bodies Accessibility Regulations 2018
Understanding accessibility requirements for public sector bodies

Web Content Accessibility Guidelines

The WCAG (Web Content Accessibility Guidelines) provides technical specifications to improve the accessibility of web content, websites and web applications on desktop computers, laptops, tablets and mobile devices for people with a wide range of disabilities, including auditory, cognitive, neurological, physical, speech and visual disabilities. WCAG 2.2 have a list of “success criteria,” or requirements for making content – including text, images, sounds, code and markup – more accessible. There are three levels of conformance: A (minimum accessibility), AA (addresses the most common accessibility issues) and AAA (the highest standard).
Under GDS rules, at the NHS Business Services Authority we are required to meet AA standard.

Source - WCAG

The Must-Have WCAG 2.2 Checklist

What are the key stages of accessibility?

There are six key stages to ensure accessibility:

• product and delivery
• user research
• content
• design
• development
• testing

Please ensure that through every stage of the process, the correct individuals are consulting the appropriate guidance to their stage of work.

Alternative options for an equivalent experience

There should always be an alternative option available for a user to gain an equivalent experience. The alternative should be in text format.
Some examples of this include:

• text alternatives for people who struggle with charts
• the ability to toggle between a chart and a table
• the ability to toggle between a chart and text
• including alt text for screen reader users
• not including images of text as they are hard to read, all text should be outside in the body of the text

Source - alternative options

Power BI toggle chart example
Text descriptions for data visualisations

Accessibility Testing

The playbook contains comprehensive guidance for testing.

The NHSBSA accessibility testing framework, guidance and toolkit can be found for internal colleagues on the NHSBSA’s Confluence instance, containing the different test stages and how to create an Accessibility statement. The toolkit and checklists were created by the NHSBSA Test community for use across the organisation.

The testing toolkit is currently being updated to ensure data products are accessible for users. Ensure you use assistive technologies and complete the usual testing process whilst this is in development.

Testing is to be carried out by local teams, but testers can give consultation if needed.

---

Improve the playbook

If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.

Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.