Interview: Alistair Duggin, head of accessibility, Government Digital Service

Sharing digital best practice

As GDS moves to a more collaborative approach – or, as Stephen Forewshew-Cain put it at the annual Sprint event, “helping departments help themselves” – Duggin’s job is to help both GDS and government departments design and build services while considering access needs.

“It’s about building things that are flexible enough to accommodate the needs of a wide variety of people, and providing alternative channels if necessary,” he says.

Five months into his role at GDS, Duggin has been travelling the country meeting different departments and teams to find out how they are approaching issues related to accessibility.

“Some departments and teams are doing really well, and others have a much lower awareness of accessibility needs,” he says.

Duggin aims to establish a cross-government community, connecting those that are doing well with those that have a lower understanding and are “potentially scared of accessibility”.

“It’s a very broad topic and a steep learning curve,” he says. “If it’s the first time they have to think of accessibility, it can become big and scary, but if you can connect them with the teams that are doing well and sharing best practice, you reduce that barrier to entry.”

Making government services accessible

The key when designing accessible digital services, he says, is to think of accessibility early on in the process.

“If you start thinking about it at the end, just before you go live, you’re likely to find lots of issues. Whereas if you help to make a team aware of the issue at the start of the project, and provide the support they need to make an accessible service, things become a lot easier.”

There are three main areas that can make a service either inaccessible or accessible.

One is the actual content. “If you’re using really complex language and not focusing on what people are actually trying to do with the service, it’s going to be really hard to use, especially for people with cognitive impairments, but also for people with literacy problems,” says Duggin.

The second part is the interaction and visual design. If a service has small fonts and low colour contrasts, or if there isn’t consistency across different pages, that can be a big problem.

The third is the underlying code used to build the service. Many people with disabilities use assistive technologies, but if the code isn’t up to scratch, the assistive technology won’t work, says Duggin.

“If you’re using really complex language and not focusing on what people are actually trying to do with the service, it’s going to be really hard to use”

Alistair Duggin, GDS

While there is a style guide with end design patterns showing how an accessible service should look, coding in a way that makes services accessible can be difficult if you don’t know where to begin. “We don’t have many good code examples, so many teams will try to implement the same things and make the same mistakes,” he says.

To resolve that, Duggin is working on a project to identify common building blocks and make an accessible version of them. These will then be tested on a range of assistive technologies and by people with a range of access needs.

“If we’ve got something that’s not quite accessible, we will fix it and make it accessible. We will have a library of accessible building blocks so people can come and borrow the code, which will get them making accessible things a lot quicker and easier,” he says.

Building a digital accessibility team

Still new to his role, Duggin is in the process of growing his team, which currently consists only of himself and a part-time consultant.

“Some of my job is about going around to departments and finding people who are working on projects that need support and identifying people with accessibility experience so I can get them into the community,” he says.

Meeting real people having problems with accessibility, he says, has helped form a strategy on how to fix it.

Many departments may have people who are new to digital, and Duggin says adding accessibility to that is just “one more complicated thing to get your head around”. 

“By making government services available, we are genuinely helping people, which is really satisfying”

Following GDS’s principles around government as a platform, and building services once, rather than duplicating things, Duggin is trying to help solve the complex problems around accessibility and make them available for people to utilise.

“Trying to teach each individual team how to do it would require enormous resources and time. At GDS, if we get to solve some of the complex problems and package them up in ways that people can use easily, that’s really scalable and efficient. It also leads to consistency between services, which is great for users,” he says. 

A front-end developer by background, Duggin became interested in accessibility while working at the BBC. As the lead front-end developer for the London Olympics project, Duggin worked to create a community of people working in accessibility, as well as a component library where different teams could share code – much of what he is now trying to implement in government. 

His childhood also inspired his passion for accessibility. “As a kid I had a really bad stutter, and I struggled with communicating, but digital technology transformed that for me,” he says.

Part of his reason for joining GDS is that he wants to help change people’s lives. “By making government services available, we are genuinely helping people, which is really satisfying,” he says. 

“If we don’t make our digital services accessible, not only are we discriminating against some people, but those people will be forced to use non-digital channels, which are much more expensive to run and much more expensive per person.”