Building a digitally accessible front door to the NHS
Building a mobile app that is accessible for as many people as possible is at the very heart of what we are doing with the NHS App.
The task we have been given is ambitious: to build a digital ‘front door’ to the NHS — a single, easy-to-use way for the public in England to access their universal healthcare system. It is simply not an option to build an app that excludes many of the people who most rely on this system.
For a product development team, this can be a huge but also very exciting challenge. Some examples of these challenges include ensuring the app meets the needs of those with:
We have used the Web Content Accessibility Guidelines (WCAG), an internationally recognised set of recommendations for improving web accessibility, to provide a framework for this work. The latest version – WCAG 2.1 – was released last summer, and introduced 17 new guidelines including improving accessibility for users with cognitive differences and sharpening up advice relating to mobile platforms.
In 2018, we achieved AA compliance, the second highest level of classification. It was the culmination of more than six months of dedicated work across our team.
In the first phase of the project, we generated a spreadsheet to cover all WCAG testing requirements that were relevant. This included a matrix comprising all screens in the app—and gave us a structure to test to ensure all users would find the app’s functions perceivable, operable, understandable and robust (WCAG’s four design principles).
Rather than tackling a large number of elements in the spreadsheet in sequence, we grouped testing by screen and by focus area, and generated a mind map, which is a visual-spacial way of grouping related themes, for each user story. This approach boosted productivity – as similar areas of testing were batched together, it allowed the team to focus on specific areas of testing more efficiently. The master spreadsheet was continually updated to document progress through these themes, journeys and pages. A significant part of the manual testing work involved deploying the app onto a variety of devices, so we could investigate how it worked on iOS and Android, as well as on old and new hardware from a range of manufacturers. Our testers systematically tested functionality on each device to ensure that the built-in screen readers were working correctly with the app.
We began our journey with a small functional test team. Early on, we realised that while we had broad expertise in accessibility, we lacked depth of understanding in specific areas. We engaged with industry experts at the Digital Accessibility Centre where testers have assisted needs and worked closely with them to put our app through its paces. We observed how the not-for profit organisation conducted tests and used the app on the premises. This collaborative approach allowed us to get testing exposure in the areas we recognised were less well understood. We saw first-hand how the NHS App affected users with accessibility needs. For example, changing the voiceover tag from ‘A-Z‘ to ’A to Z’ may seem like a small detail, but for someone using a screen reader, it was important. We found the screen readers were ignoring the dash and just reading the ’A‘.
We shared our growing expertise with the wider team through knowledge-share sessions. We then adapted our ways of working to incorporate these new techniques as part of our development “checklist” for new features.
Our initial audit resulted in a document which highlighted any key issues with the app. We were somewhat relieved to find there were no major issues that hadn’t already been identified within the team. We went through the feedback, identifying one-off or recurring issues and working through them to understand how we could improve our internal processes. In some areas, we asked for further feedback on our solutions and worked closely with specialist suppliers to ensure these were implemented correctly. Once we were confident we had fixed all the outstanding issues, we arranged for a retest and were overjoyed to hear we had achieved WCAG 2.1 accreditation!
In addition to this testing, our User Research team recruited users with varying accessibility needs to test the app throughout the development journey. This provided the iterative design, development and test functions within the team with direct feedback on successes and pain points as functionality evolved. In parallel, we have been fully engaged with the Government Digital Service, who gave us valuable insight into the common accessibility pitfalls for projects like ours.
It’s still early days in our accessibility journey. Work on the app is moving fast and new functions are continually being added. This means a continuous effort to test, improve and retest accessibility for people with all sorts of needs, from mobility, and vision issues, to cognitive differences like autism and dyslexia. We are always looking to improve our understanding of individuals’ needs, but there is a real sense of achievement in our team that we have got this far.
Originally published here.
