Making services accessible means making services that anyone can use. It means creating and running them so that no one is excluded, whether they have a disability or not.
From our discussions around government and from our growing accessibility community, we know that people in government really care about accessibility. We know that there is a desire to make things as accessible as possible.
But we also know that people can find accessibility hard. We see this from the requests for help and training that the Accessibility team gets. And we see it when service teams face issues in audits and service assessments.
We wanted to know how we could better help teams make accessible services. To do this, we wanted to find out how they were going about accessibility at the moment – what their processes were and what they found most challenging.
So we carried out a discovery.
We spoke to 14 delivery teams and 8 individuals across 8 departments and agencies – including GDS. The people we spoke to included developers, user researchers, product owners and service assessors.
We also did desk research on the common issues that came out of formal and informal reviews and thematic analysis on threads in the cross-government Accessibility Google group.
Our research showed us some of the common challenges. Some of the things that service teams consistently find difficult. Some of the areas that we can develop common solutions to. Here are some of the things we found.
Raising awareness and understanding
Our research found that there isn’t a common understanding of what accessibility means. It isn’t just about making things work for blind people, which is a common misconception. It’s about the diversity of human capability.
There is plenty of guidance available around accessibility. The Web Content Accessibility Guidelines 2.0, for example, is a recognised, well-used set of guidelines. But they are very long and use lots of technical language. We found that many people were overwhelmed by the amount of accessibility information online.
Also, lots of tools are available to test websites for issues around accessibility. But it’s not always easy for teams to work out how to use these tools in the best way. And how to combine them with manual checking. We’ve carried out further research into using accessibility tools and we’ll be sharing this soon.
Sometimes definitive answers are not the solutions people are looking for. People need to be guided and gain experience.
This leads to the second major challenge we found.
Raising confidence around accessibility
We found that while teams have a desire to make accessible services, confidence can be a big barrier. So, for example, we found that user researchers can lack confidence in conducting research with people with disabilities. And developers often weren’t confident about testing their services with a range of assistive technologies.
And a fundamental issue for teams is that they can struggle to find research participants with disabilities – including people who use assistive technology – to test their services with.
We found that one of the things that can help to build confidence is to have clarity on who is responsible for accessibility on a team. And for accessibility to be considered at the start of a project.
If a team lacks confidence around accessibility, this can make it hard for them to tackle what we found was the third major challenge.
Tackling time and money constraints
Our research found that time is a big issue. Teams are often under tight deadlines to deliver. When time is short, accessibility is one of the things that can get put off until later. But not considering accessibility from the start can lead to teams having to fix issues later in the project, which can be more expensive and time-consuming. One team reported a case where it took 2 to 3 sprints to deal with accessibility issues defined in an audit, at a cost of £50,000.
Money can be a constraint elsewhere in projects. We found teams that struggled to get the budget to pay participants for user research. Accessibility audits can help to identify issues with a service, but these can cost £6,000 to £7,000, and not all teams are able to easily meet this cost.
More structure to assessment
We found opportunities for the Service Assessment process to better support teams looking at accessibility issues.
We found that assessors wanted more help to know what they should be asking around accessibility. And they wanted examples of what good looks like.
What we’re doing about this
Through our research we met a lot of people with a genuine desire to make services that everyone can use. And we got an understanding of how we can better help them.
We want to build on this. We want to support and enable these teams. We want to create culture change. We want to empower teams across government to look at accessibility as an intrinsic part of end-to-end service design.
We’ve seen how fast the accessibility community has grown across government (from zero to 400 in 5 months) and we can work with the community to come up with and test solutions and to make change.
Based on the findings from the research, we’re looking at ways to:
- raise awareness of the fundamentals of accessibility
- define and explain what teams have to do to create accessible services
- provide easy access to resources on how to make different parts of a service accessible
- ensure government design patterns are as accessible as possible
- help to improve service assessments to ensure that services are accessible to as many people as people
We’ll be sharing more on our work soon.
