DWP’s services are used by almost everyone in the UK at some point in their lives. So, it’s crucial we design these services to be fully accessible to all, ensuring they fall in line with accessibility regulations.
In the latest episode of the DWP Digital Podcast we’re joined by Calei Smith and Craig Abbott who lead on accessibility for DWP’s internal and external services. They discuss the common challenges faced when making sure services are accessible for everyone, the rules and guidelines that we need to follow, and the story behind DWP’s Accessibility Manual.
A full transcript of the episode can be found below.
Join us on our journey
Over the next few months we’ll be speaking to more of our in-house digital experts and leaders about some of the exciting projects we’re working on that are helping transform experiences for millions of people.
Make sure you don’t miss an episode by subscribing to the DWP Digital podcast on Apple Podcasts, Google Podcasts and Spotify and by following #DWPDigitalPodcasts.
And if like what you hear, don’t forget to give us a 5-star rating.
Welcome, everybody, to another episode of DWP Digital's podcast. My name is Stuart and today we're talking about the importance of accessibility, the challenges we all face and the best ways to make your services accessible.
And don't forget, if you're interested in technology and the types of things we do, hit the subscribe button now, so you don't miss an episode.
So let's get started. Calei, Craig, would you like to introduce yourselves?
So hello, my name is Calei Smith. And I'm the Head of Accessibility for all DWP colleague-facing services, focusing primarily on assistive technologies or different assistive tech to enable and empower everyone to work.
Before I joined the team last year, I worked as a product owner or product manager in various different roles in the public sector. I'd say my primary focus or passion is designing and creating services for people who need them, with the people who use them. And I think it's really important to ensure that the user has a voice.
I'm Craig, I'm also the Head of Accessibility, but I sit in product design and strategic planning. I'm focused mainly on making sure that our services can be used by anyone, and that they fall in line with the regulations.
Before doing this role, I was a senior interaction designer in the department building digital services for several years. Always kind of been a designer for user needs and took a particular interest and accessibility. So just kind of progressed into this role through passion for it.
So you both work in different teams, can you tell me a little bit about them and their purpose?
So the team that I head up is the accessibility technology service, which is comprised of 3 teams. There's a product team, a service management team, and a centre of excellence. And essentially, our focus as a team is about all DWP colleagues who may have any form of accessibility needs or any cognitive or physical impairment.
We support about 1,000 assistive software users and about 10,000 hardware users. So that hardware might be anything from a small peripheral, a mouse or a keyboard, up to some really big tech, just really depending on the needs of the individual.
Our focus is anybody employed in DWP, who might need any help. And it's really about understanding any of the barriers or challenges any of our colleagues face, in terms of accessibility and how we might be able to better support them. And not only support them, but support their line manager and the teams that they work within.
So my team, the work that we're doing is very much focused on kind of accessibility compliance. So we're looking at digital services, we’re looking at the regulations, which came in fairly recently. So we got, you know, the Public Sector Bodies Accessibility Regulations that came in 2018, there's a standard that is legally got to be met. So you know, we've got the Web Content Accessibility Guidelines, we've got to make sure that our services are meeting the right standard of those. And we've got things like accessibility statements on the service and stuff.
So a lot of the work that me and my team are doing are, we're testing services, we're auditing services, we're making sure that they meet the technical aspect of accessibility, that they work with things like assistive technologies, like screen readers, and that kind of thing. But ultimately, that were fulfilling our legislative requirements, and that we're meeting the right standards when we push services out there.
So you know, internal services apply in the same way. So, if we've got a service which staff are using, the same laws and stuff apply, so what kind of just looking at compliance and standards across all of our digital services, to make sure that everyone can use them, essentially.
In your experience, how are companies addressing people's needs? And what are the common challenges companies or services face?
I think, because it's mandatory now for public sector bodies, it has massively improved things, but for private sector companies, a lot of the time, unfortunately, we don't really see the benefits of doing accessibility work. Or they don't see, you know, the way that it could potentially make people's lives better or the fact that it could potentially bring them more revenue, they kind of miss these points, and they just focus on the expense side, “Oh, I'm not going to do accessibility because it's expensive.”
But I think, you know, in government, because we are mandated to do it, it tends to be a bit better I think. We kind of been doing user-centred design for quite a few years now. So we do benefit from years of trying to be more inclusive and trying to simplify the designs. We do user research. We've got things like the Gov UK design system now where we get a lot of accessibility built into the components that we use.
I suppose everyone kind of there's a running joke that Gov UK services are quite ugly. And if you're a designer, you're just kind of bolting things together. But I suppose there's a beauty in the simplicity in the fact that it is relatively simple for everyone to use. And also you get the accessibility stuff baked in. So it's better to, I suppose, be a bit ugly and have it work for people as opposed to, you know, when you get private sector companies trying to give their brand a voice and do kind of all of this, the more sort of fancy and fashionable type design that is then ultimately more difficult to make accessible. So I think the current state, it's definitely better than it perhaps was. But again, you know, we're probably still quite a way away from being perfect, both in the private and the public sector.
My opinion of the current state of accessibility is that it's very mixed. I think there are varying appetites when it comes to accessibility, and varying degrees of comprehension and understanding. I do think, in terms of public sector, the public sector regulations, do mean that we have a clear mandated law, or legal requirement really, that lets us work with teams to make sure that we are making accessible services.
I think what's quite heartening to see is that some of the private organisations that I've had some contact with, or attended meetups with about accessibility are now also trying to get ahead of those regulations, and trying to basically bring up their standard of accessibility. But generally, I'd say, across our department, I think people are very keen to try and understand more, and how they can make services more accessible, and actually work with our accessibility community, to get them involved in testing and research.
One of the biggest mistakes that I see is people making things unnecessarily complex. As an interaction designer, you know, I'd spend more time trying to remove things from a service, then I would probably designing new things. There's a lot of times where people just try and put stuff in and say, “Oh, this is a bit complex, so we'll add a load of additional content in there to explain it.” Or, “We'll send out a 32 page booklet with this form to explain how to fill it in.” And that kind of thing, I think, the more stuff that you can remove, the better.
We need everything to be as simple as possible. And the more things that you add, the more complex it becomes. And the more time you've got to spend making those complex interactions accessible. So things like pop ups, or slide out panels, or animations, and all of these additional layers create barriers for people. So I think, you know, anything can be made accessible, it's just it requires a lot more work to make the fancier things accessible.
So I think the common challenge that we still face is that sometimes accessibility is still seen as either a nice to have or something that's too complex to resolve. And I think it's sometimes that understanding, or some of the limitations that people have around accessibility, that can hold them back.
Sometimes the other challenge is that it's left to the last minute, or it can be a bit of an afterthought. So people trying to retrofit accessibility into products and services they've designed which can make it really complex and sometimes more expensive. And in some cases, it's just not done at all. And we end up in cases where we have to support people who are working with products and services that aren't accessible.
Generally, I'd say that is the exception rather than the norm. And a lot of the time, a lot of the engagement our teams have in the department is either working with people to better support people or make accessible products or learning or training, or various things that people might want to use. But generally, I I think it's just knowing where to start that sometimes holds people back.
So what rules or guides do we follow and how do we check that our work is accessible?
There's these things called the Web Content Accessibility Guidelines (WCAG). And they've got three different levels, there's A, AA and AAA. Each one gets increasingly more advanced I suppose, they have more criteria that you have to meet. So we've got to go in the middle, we've got to be AA compliant. That means there's about 50 things that we need to make sure that we cover off. So it'll be things like font size, colour contrasts, you've got to make sure that, you know, you can use a keyboard to navigate the service, that kind of thing. There's 50 different sort of points that we have to hit.
So, in order to test that we meet all of them points. There's a combination of kind of automated and manual tests that we do. So we can use things like aXe and Wave which will just run automated tests and they'll in about 5 or 6 seconds, they'll tell you if you've got any violations on the page. But they'll find common things like if you've missed alternative text for an image or something like that. But we do know that if you use aXe Core, sorry if you use aXe and Wave together, you would still only find around 40% of the known issues. So you absolutely can't just rely on these automated tools, we need to kind of use them as a first check.
Once everything is passing the automated tests, we move on to the manual tests, where we literally go through every one of the 50 different criteria of WCAG, and we manually check the page. So there is a plugin called accessibility insights, which will walk you through that process. Or you can just pull up the WCAG documentation and go through that.
We've got a spreadsheet which we use, it has the 50 criteria, and it has how you kind of check for those things. But it will require somebody to go through and manually check things to make sure that they make sense because automated tools can't pick up things like whether your links make sense it you know, it doesn't really understand English language, therefore it can't tell you if your links confusing or not, it can just tell you if you've coded up correctly. So we need to then do all of those manual checks to make sure that it's meeting those criteria.
And then once it's kind of meeting all those things, we just need to make sure that does work with assistive technology, because something could look right and it can behave with a mouse and it can behave with a keyboard. But then you try and use something like a screen reader. And if it's reading things out in the wrong order, or it gets particularly confusing because it's mispronouncing something, then we need to find those problems and fix them as well. So we've got a few different steps that we need to put in place.
And you know, automated is one thing, manual’s another but I think the step that a lot of people miss is that assistive technology testing. It is part of what WCAG but it's not that clear. So we kind of call it out specifically and say you know, you need to test it with a screen reader voice recognition software and a screen magnifier.
So within DWP, the main assistive software technologies we use are JAWS, which is Job Access With Speech. We have Read&Write which is primarily a dyslexia tool. We have ZoomText, which is a screen magnifier. We also have Supernova, which is another screen magnifier for a couple of our users. And we also have Dragon which is a dictation tool. And essentially, what we do is we work with users to understand what needs they have.
So they have an assessment, which will identify any workplace adjustment they need. And then we spend some time with the user, getting them tested up in that piece of assistive software. So they'll have training on that software. And then they'll have an AS buddy who will support them if they have any issues, or any problems with the software.
And what we do is we work with product teams, as we roll out any of those software. So we are going through a process of upgrading all of them, and understanding how that impacts users within the department. And not only that, but we are looking to see whether or not those products are the right tools.
So recently, we've been doing a comparison of one of our dyslexia tools, which I mentioned was Read&Write. And we're actually looking to see whether or not that's the best tool. So we've been doing some user research with the users of that tool to test against other products on the market. And we've actually identified something else we're going to migrate users across from over the next year.
But as we do with anything that we bring into the department, we test them against those same WCAG requirements to make sure that the products we bring in are also accessible. And interestingly, we did have a recommendation for a particular product, which supported dyslexia. When we tested that tool, we found A, it wasn't the best tool. And B, it wasn't actually accessible ironically, in some of the cases.
So we decided not to use that tool and go with another. So we are constantly reviewing not only whether or not the tools meet the needs that are identified by our users, but whether or not there's anything out there that's better suited. And whenever we bring that in, it goes through user testing that the people be using it because obviously, at the end of the day, we are not experts in that field, but the individual user is going to be using this software. So they need to really be able to have something that really fits for purpose.
Not only that, but we take it through various governance gateways to make sure that everything we bring in not only meets our accessibility standards, but we've got the right security in place and making sure that we bring in the right products in the department.
How far reaching is our work across government? What impact if any, does it have the beyond our four walls?
A lot of the things that we are doing isn’t too dissimilar to other services, but we're all tackling accessibility in slightly different ways. I think the main thing is though, that there is a lot of learning and new opportunities that we are exploring ourselves that I'm very keen for us to share. Because ultimately, we all have the same goals, the same ambition, which is making good services and good working environments that everybody can use.
So I think by working with those other organisations, we do try and see where other errors and implementing things that we would want to bring in. So, one of the other government organisations has accessibility training for all colleagues. So that good baseline knowledge and awareness is there. And that's something, that's one of the aspirations Craig and I both have for what we'd like to see in the department, the DWP as well.
So I think yeah, just working through sharing what we've learnt and working with cross gov meetups, I think is a really good way of seeing what learning we can bring back to the department.
Even when I was a designer, I've always been a massive advocate for working in the open. I've always kind of attended cross government design meetups and those sorts of things. We've got a cross government accessibility meetup, which I tend to go to.
So I guess when you know, any of the work that I'm doing now, in this role, I apply the same principles to. You know, the accessibility manual, for example, it's just kind of out there, anyone can use it, you can use the code for your own project, or you can kind of contribute to ours. I think sharing stuff and making things open always makes things better. And I think if everyone's able to contribute to those things, we don't end up with multiple sources of the truth, which It's really annoying when you've got two very similar things and you don't really know which one to use.
But I think there's quite a good accessibility community building up across government. I know Calei and I often are on the same calls, we talk to the other heads of accessibility in other departments and things like that. And I think it is good just to stay kind of hooked into what everything every other department’s doing ‘cause everyone is doing slightly different things and tackling accessibility in slightly different ways. So staying in tune with what everyone's doing, and kind of sharing the stuff that we're doing as well, I think is really important. And we'll continue to do that.
Craig, you've just mentioned an accessibility manual. Can you tell us a little bit more about that?
Yeah, so the accessibility manual kind of came about. You know, we did some user research, we found out that accessibility is not very well understood. So I suppose like with all good things it started from user needs. A user researcher called Emma Nicol gave me a hand to survey all the different roles across digital. We surveyed, you know, product managers, delivery managers, designers, developers, QA testers, all the roles you'd expect to see in a team. I think there was about 220 people responded.
And I suppose what became quite apparent is that people didn't understand exactly what they needed to do, you know. There was quite high awareness of accessibility, which is really good, but not a lot of understanding as to exactly what it means for teams and that kind of thing.
So I suppose for some roles, it's more obvious than others, you know, designers and developers tended to have a better handle on it than business analysts, for example. But kind of by the by, I suppose what came out was a strong insight was that, you know, there was just a lack of guidance or lack of training, people weren't really sure what to do and where the best place to go for information was. So there's guidance scattered all across the Gov.UK, we've got the service manual, there’s Gov.UK guidance, there's all kinds of different things.
But the idea of the manual was just to pull it all in one place so it was easier to find. And but also to break it down by job role. So just the fact that we got so many responses from so many different roles, it became quite clear that it would be useful to tell people exactly what they needed to consider and kind of what their responsibilities were, rather than them just making assumptions that it was up to the developer or whatever.
So what details do you have in your manual? What does it cover? And what advice do you give?
In the document, or in the manual I guess, there's a bunch of different sections. So one of the things that was confusing people was the different legislations and accessibility falls into at least three pieces of legislation from the last 10 years and people weren't always clear, exactly kind of which ones it fell into and what that looked like. So we've got a section for accessibility law, where it literally just looks at things like the Public Sector Bodies Accessibility Regulations, the Equality Act, and it kind of talks around things that you need, you know, what WCAG 2.1 and accessibility statements and that kind of thing.
The section that probably gets the most feedback is the guidance for your job role. As I briefly mentioned before, you know, there's a whole section which you can go in, and you can say, “I'm a designer, what kind of considerations do I need to do accessibility?” And it'll tell you things, you know, if you're an interaction designer, you need to consider you know, are you using buttons instead of links and that kind of thing, so it’ll break things down as different things you can check in, make sure that you've kind of covered off.
It also has best practices in there. So you know, if you're building a digital service, what does the process looked like? So, you know, you might have in there kind of the process from start to finish. So you know, you build a page, then you want to be run an automated accessibility tools against that in the browser, that's kind of your first port of call, then you want to be doing manual accessibility checks. So you could use something like accessibility insights, which is a Chrome plugin, to kind of do the manual checks, then you want to go on to doing the assistive technology testing. So you're doing things like voiceover, voice control, that kind of thing. And then before you push your code, you might want to have embedded an automated checker into your continuous integration pipeline. So every time you push code, that's going to run and make sure that you haven't got any silly mistakes, it’ll reject the code if it's bad, that kind of thing.
So there's a lot of kind of best practices and processes in there, where it’ll talk you through what's the most efficient way, I suppose, to get to that point where your thing’s compliant, because if you do them in the wrong order, if you do the assistive technology testing first, and then you find that it's failing on an automated tool, you've then got to do all of that assistive technology testing again, so it's kind of a step by step thing as to what's the most efficient way to do it, I suppose.
And then there's just a pile of tools and resources in there, blog posts, videos, and links to things that other departments have done. Like there’s a really good resource called Sculpt, which is about document accessibility and that kind of thing, by Worcestershire County Council. So there's a whole bunch of resources and stuff in there, which we just link off to. So yeah, it's broken down into four or five main sections. But we just tried to cover all of the gaps that we found in the research.
So if anyone's looking to pick up a copy, where can they find it?
So you can just go to accessibility-manual.dwp.gov.uk And that's where it lives. If you wanted to steal the code, I suppose and write your own manual, it's also on GitHub, which is linked to from the same URL.
Thanks a lot. That's great.
So what are we putting in place to make sure our future services are accessible?
So the accessibility technology service, as I mentioned, is comprised of 3 teams. We've gone through a fair bit of development to make those 3teams really focused around user needs. So some of the priorities we're working on at the moment is the upgrade plans for all of the assistive software. We're getting those mapped out and shared, not only with our stakeholders, but with our users as well. So people who use assistive tech or assistive software like JAWS know when they're going to get the latest version. We are working to make sure that all of our assistive software is upgraded to the latest version.
We're doing a discovery on common barriers and problems faced by our colleagues in DWP around not only accessing accessibility support, but making sure they have support from their line managers. And again, through education, and development of some training materials for line managers, we should hopefully see better support there.
And the monthly accessibility show and tells, again aren't just focused on tech. It's focused on accessibility across DWP, and is really primarily focused at our users, but also looking at going out to product teams, and letting them know about the standards, the guidelines, but taking them from being something that isn't just a tick box, but actually represents the people that are impacted by accessibility requirements. So by working with product teams, what we'd like to see in those show and tells are essentially good examples of accessible services or good learning when somebody has taken something that's been inaccessible, and turned it into an accessible service, and really taking something that feels sometimes like a tick box and turning it into something that's really realistic, pragmatic, and is sometimes a bit demystified as well.
So things that I'm currently working on, the exciting stuff, I guess, is looking at training. So we're busy working on an introduction to accessibility course, which is going to be very high level just to kind of start with, but we're hoping to have a series of training courses so they'll kind of gradually go into more depth and maybe branch out into different roles. So obviously like a content designer would be very different from a QA tester or something, but at the moment, it's just going to be a very high level overview of accessibility. So that's quite exciting.
I suppose, on the other hand, a lot of audit work that I've been doing just to kind of work out what services look like across digital, you know, out of all of our digital services, which ones are compliant, which ones aren't, and kind of where we can get those ones up to scratch and stuff. So it's been quite unglamorous work, I suppose. It's been about three months of just going around different areas of you know, what is a massive organisation and talking to dozens and dozens of people to find out exactly, you know, what each service looks like under the hood and kind of where it's at, so. But yeah, it's been worth doing, it gives us a picture of where we're at, and it gives us something there to move towards.
So what would you like to see us achieve in the next few years regarding accessibility?
For me, I think, as I kind of mentioned earlier, I'd like to get to a point where we can lead by example. And I think not just with regards to the work that we're doing, or you know, what other government departments are doing. But I think there's generally a better wareness and a better way of measuring accessibility, you know, it keeps getting iterated. So I think we've mentioned WCAG, a few times we're on version 2.1. 2.2, will be coming out later this year. And then they're busy working on version 3.0, as well. And 3.0, is the first time they've tried to address, at the moment, compliance is kind of binary, you can either be compliant or non-compliant, but there's no measure of how good or bad something is, you know, something can be non-compliant, but be 99% there, and something can be non-compliant and be 1% there and there's no way to differentiate at the moment.
So with WCAG 3.0, they're looking to address that with like a bronze, silver and gold kind of tier. So there's a better way to measure stuff. And I guess, in the future, I just hope that the legislation and the work that we're doing in government and stuff continues to get better. And we continue to adopt the new standards. And we continue to just get everything better and get everything as good as it can be. Because what WCAG 2.1 definitely isn't without its short comings. So I think if we just focus on that, then that needs to be the bare minimum, we need to be doing way more than just that. And I think over the next few years, I'd like to get to that point, I think.
I think for me, over the past year and a bit that I've been working in the team, I've really seen accessibility become more of a widespread topic. And it's really heartening to go into a meeting and not be the one to raise accessibility. So I'm noticing a lot more teams raising accessibility almost as a core thing, as part of either their development or their rollout plan. Or even just designing new services or products or features. They're thinking about accessibility earlier and earlier, which is really heartening to see.
I think that's down to a number of factors, I thin, the tremendous work that's happening across the department and the work that our team’s doing that Craig's team’s doing. Debbie Ralph in the shared communications channel, doing a lot of great work there. Becca Landers and our people and our capability team are doing a lot to really raise the profile of accessibility.
I think there's still a lot more we can do. And we're definitely not getting it right 100% of the time, and I think my aspiration will be that the department is a leader in accessibility. And I think not only leading in how we support colleagues and citizens, but also how we support other government organisations, and share what we've learned along the way really, which I think is key.
But I think, more importantly, the department is really focusing on the needs of users, rather than our assumptions on accessibility, which I think is really, really vital to help us address this issue.
So that ends our podcast for today.
Hit the subscribe button if you want to make sure you don't miss the next episode.
And I'd like to thank Calei and Craig for taking part today. I found their views on accessibility really interesting, and I hope you did too.
So thanks for tuning in. And I'll see you next time on the DWP Digital podcast.