To mark Global Accessibility Awareness Day, PublicTechnology caught up with Craig Abbott from the DWP to discuss how the department incorporates inclusion into its services, and why inaccessibility equates to discrimination
Credit for all pictures: Crown Copyright/Open Government Licence v3.0
Making products and services as accessible for customers as possible is – or at least should be – an important and growing consideration for many organisations.
But most businesses do not have a customer base of 67 million people.
Holding responsibility for benefits, employment issues, and the state pension, the Department for Work and Pensions, in some way shape of form, provides services to more or less the country’s entire population.
And with those services including crucial support mechanisms such as Universal Credit, leaving any users behind is not an option.
To mark Global Accessibility Awareness Day, PublicTechnology caught up with the department’s head of accessibility Craig Abbott (pictured below right) to discuss the importance of inclusion, how best to embed it in service development and design, and why government’s work is not done until it is completely accessible.
PublicTechnology: Broadly, what is the importance of accessibility in service design and delivery?
Craig Abbott: Accessibility at its very core is a user need. So, if you’re truly doing user-centred design, then accessibility is as important as any other part of the service. I think people often look at accessibility as a feature, technical debt or something to prioritise against other things in the backlog, when actually, it should be a part of everything you deliver. You cannot disconnect the feature or the service from the accessibility work or you start to stray into the realms of discrimination.
Discrimination is a hard word. I imagine anyone would be horrified if you accused them of discriminating against people with impairments. But if you deliberately release inaccessible services, that’s exactly what you’re doing.
We’ve put together some accessibility principles, one of which is ‘if it’s not accessible, it’s not done’. I think this is a good way to look at it. If it’s not accessible, you can’t deliver it. And, if you’re in the business of delivering services, I’d say that’s pretty important.
What do we mean by accessibility, and what are some of the user needs, circumstances, and experiences that need to be considered?
The word accessibility has become a bit of a buzz word. As you can probably guess, it is derived from the word access. It basically just means that anyone that needs to access something can, regardless of what impairments they might have or what tools they may use. You could be trying to access a building as a wheelchair user, or you could be trying to access a digital service as screen-reader user. When we say it’s accessible, we just mean that you can access that thing regardless of your situation, because the environment has been designed to cater for a range of different needs.
Sometimes digital accessibility gets mixed up with ‘assisted digital’. If something is accessible, it doesn’t mean it will suddenly be usable for everybody.
Digital accessibility means people with good digital skills can use the service with their tools of choice and it will behave as expected. But there are many reasons why some people may never use a digital service. My grandad often couldn’t even figure out the TV remote, so he would never have attempted to claim his pension online. People with low digital skills like my grandad are unlikely to ever use a digital service because they don’t have the confidence to do so. So, we need still to offer assistance face-to-face or on the phone so that these people aren’t excluded.
How do you best incorporate these experiences during the design process?
I think accessibility is often seen as a technical problem. There is a misconception that the responsibility is on the developer to write the code correctly so that it works as expected. But, actually, everybody on the team has a responsibility.
We’ve produced guidance for each of the different job roles. We found this helps everyone to start considering and owning their own little part of it. For example, content designers often didn’t know they should design human-readable URLs. So, the links in the service would just be random characters and parameters from whatever framework the service was built on. This can cause problems for people using screen readers.
Another really useful tool is the GOV.UK accessibility personas (pictured above). There’s eight really detailed profiles specifically designed to help you think about how people with accessibility needs might try and access your service. I’d definitely recommend using these in your design process, it will help you discover any gaps you might have missed such as how this might work for somebody who has a visual or motor impairment. They really help to keep the accessibility discussion on people rather than requirements.
At what point in the process does accessibility enter your considerations? And how does it then feed into each stage of the process from there – including once a service is live?
You should be considering accessibility right off the bat. In discovery, when you’re trying to establish who your users are and what their needs are, then you need to include people who have access needs. As we mentioned earlier, if we’re doing true user-centred design we need to design for the needs of everybody.
Once you move into alpha and you start designing ideas, again you need to think about how these will work for people with impairments. You should be using the knowledge you have on your users and the accessibility guidance for your job role to really design a service which can be used by anyone. By the end of Alpha, you should know that the thing you plan to build can be made accessible, and you should have a good understanding of your responsibilities to meet the department’s legislative requirements.
Discrimination is a hard word. I imagine anyone would be horrified if you accused them of discriminating against people with impairments. But if you deliberately release inaccessible services, that’s exactly what you’re doing.
In beta, this is where you have to really start testing your service against the standards. When you write production code, it needs to be compliant with the Web Content Accessibility Guidelines (WCAG) 2.1 to the standard of AA. You will need to do automated, manual and assistive technology testing as part of your build, and you will need to continue to do usability testing as part of your user research. It’s best to do these as you go. A common pitfall is to leave all the accessibility testing to the end and then it becomes a bottleneck and people start trying to cut corners to make deadlines. Remember, if it’s not accessible, it’s not done.
Once your service is in public beta and live, you still need to do accessibility testing. Accessibility compliance is only a snapshot in time. If you iterate your front-end design or code, the accessibility testing needs to be re-done on those iterations to make sure you haven’t introduced any errors. Get into the habit of running automated tools in the browser, automated tools in the pipeline and manual testing as part of your acceptance tests. This way it gets estimated correctly and your deadlines won’t have to move.
At any point in the process, you should have a good feedback mechanism in place. If something isn’t working for somebody, give them a way to open a dialogue. People are more likely to work with you to fix accessibility issues if they feel like they can be heard. Inclusion is always better than empathy or assumptions.
Has the consideration government gives to accessibility needs changed – and improved – in recent years?
I think the introduction of the Public Sector Accessibility Regulations in 2018 has certainly helped. Like GDPR (General Data Protection Regulation), there was a big spotlight cast on the new legislation and it made people pay attention. The accessibility requirements were always there: they’re part of the Equality Act which has been around since 2010. But the Equality Act is huge, and it covers so many things, it isn’t easy to understand without extensive studying. Having new legislation written down in a very specific way for digital services means it’s a lot easier to unpick and understand for people.
I’d say the awareness of accessibility has definitely increased. All across government there is work going on to improve the accessibility of all services, and you’re seeing more and more departments recruiting specialists in to make sure they can deliver accessibility correctly. We’re still not where we need to be, but even in the short time I’ve been in the department I have seen huge changes.
What are the key relationships DWP has with other organisations?
GDS have done a lot of great work. The Service Standard, assessments, the Service Manual, the Design System; all of these things help other departments build solid, user-centred services which are accessible to everyone. We always encourage the use of things like GOV.UK Frontend, because if we’re all using common components and patterns, then services instantly feel familiar to citizens. There is also a lot of research in those components so they’re more likely to be accessible if you use them to their specifications. By having a two-way dialogue, it also allows us to challenge things which aren’t working. GDS are often receptive to changing the guidance if we can show that it’s not being understood or isn’t working for people.
All across government, we’re all trying to work together to make accessibility better. The Home Office, HMRC, MoJ, Scottish Government – we all have a session once a month where we can share the work we’re doing and see how we can support each other. We’re all working on accessibility, but not all on the same things at once. So if we can share a training course in exchange for some recruitment guidance, it means we can all get more done in a shorter space of time to make things better for citizens.
What are some small things that might – for many – go unnoticed, but could have a big impact on the accessibility of a service?
If I’m honest, I think all accessibility work should go unnoticed. It often only becomes noticeable when it’s a bad experience. Being compliant isn’t a badge of honour for the department to wear, it’s the bare minimum we should be doing to make sure the service will work for people.
The Web Content Accessibility Guidelines (WCAG) has three levels. There’s A, AA and AAA. You can almost treat these as an impact scale. If you have A failures, that’s going to affect more people than if you have AA failures. So I wouldn’t like to say there are some small things which have a big impact, because accessibility affects everybody differently. What might be small to one person might be a huge barrier for somebody else.
What I would say is: if you have a lot of failures, sort the A failures out first as they are likely to have a bigger impact overall.
How will DWP’s accessibility strategy and work develop over the next year or two?
The strategy I’ve been working on focusses on three key areas: compliance, culture and education. The concept is derived from the fire triangle, which is a common feature in GCSE science lessons. The idea is that if you remove one side of the triangle which represents fuel, oxygen and heat, the fire will burn out.
Accessibility is similar. If you remove compliance, culture or education, your ability to deliver accessible services burns out. A big mistake a lot of organisations make is focussing solely on compliance. But it’s like asking somebody to pass an exam without them understanding how to do it or why they even need to do it in the first place.
You can read more about Craig Abbott’s accessibility strategy.
He also recently spoke in more detail about the Accessibility Manual on the DWP Digital podcast. It is available to listen to now on Apple podcasts, Spotify, Google Podcasts and other services.
You can also access the following resources: the DWP Accessibility Manual; the Service Manual: DWP job-role guidance; accessibility personas.