Implementing an accessibility strategy for DWP

The Department for Work and Pensions is one of the largest government departments in the UK. It’s responsible for services related to social security, and is used by millions of people every day. Because of the types of services DWP provides, such as pensions and disability benefits, it naturally serves a higher proportion of people with accessibility needs than almost any other organisation.

Despite this, many services weren’t meeting the accessibility standards set by the Public Sector Bodies Accessibility Regulations, and before anything could be fixed or transformed in a sustainable way, I needed to understand why. This case study covers the work I did to understand the current landscape, define the strategy, and transform the way we did accessibility in the department.

Situation

In March 2020, during the first lockdown of the COVID-19 pandemic, I took on the role of “Head of Accessibility” at the department.

It was essentially “Head of nothing”, as we did not have an accessibility team, strategy, governance model, or any reliable supporting documentation to help digital teams deliver accessible services.

Awareness of accessibility across the organisation was reasonably good, but understanding was not. People had heard of it, and knew they needed to do something, but they weren’t confident in exactly what that was. The resources and processes around accessibility were fragmented, complex, and convoluted. Standards were low, implementation was inconsistent from team to team, and people didn’t really understand why it was even important to prioritise it.

The deadline for the Public Sector Bodies Accessibility Regulations was 23 September 2020. Once this deadline passed, any of DWP’s existing websites which were non-compliant would be breaking the law. So, the risk the department was carrying was huge. But, there was no risk assessment or risk management strategy.

Task

My task was to understand the current landscape as quickly as possible. I needed to identify the gaps, frame the problem, and then define and implement a strategy that would raise the standards of our digital services in a way which was sustainable, rather than falling into the common trap of chasing compliance through snapshots from third-party audits, which are outdated or redundant after one or two releases.

At the same time, I needed to build trust and rapport with senior leadership, help them to understand the situation, get their sponsorship and buy-in for the strategy, and help them to manage the associated risks.

Action

Research first

Coming from a user-centred design background, I didn’t want to make any assumptions as to what people needed. If there’s one thing I’ve learned from change management and digital transformation, it’s that organisational change needs to happen with people, not to people.

I teamed up with Emma Nicol, who was working as a Senior User Researcher in the department at the time, and we designed a survey to understand how much people in product teams really understood the laws, their responsibilities, and what it takes to make an accessible service.

We analysed responses from over 200 people, spanning every role you’d expect in a multidisciplinary team. We had responses from product managers, delivery managers, user researchers, content designers, interaction designers, developers, QA testers, performance analysts and business analysts.

Auditing the landscape

Alongside the research, I also conducted an audit of each functional area. These were areas of the organisation which contained many product teams working on related services. For example, “Check your State Pension”, “Pension Credit” and “Get your State Pension” were all product teams which sat in the “Retirement” function. All the teams in each function reported up to a deputy director.

The audit work involved talking to the deputy director and senior leaders in each area to understand how many digital products they had responsibility for, what the names of these products were, what their tech stack looked like, where they were in the product lifecycle, and who the best points of contact were for those services.

The reason for understanding the tech stack and where a product was in the product lifecycle was to help with prioritisation. There are some products and services which fall outside of the scope of the Public Sector Bodies Accessibility Regulations, for example, an API with no user interface. It’s still a product, and there’s still a team with responsibility for maintaining it, but it’s just two computers sending data back and forth.

From this audit work, I was able to build a complete picture of all of the digital products, guidance and processes which touched on accessibility across the department. This included who was responsible for them, whether they were a risk, and how much effort they were likely to take to get across the line.

Understanding the current state

Once I had the results from the research and from the audit, I conducted gap analysis, and it was clear that:

• Awareness was actually quite good, but standards and knowledge were low.
• Most people didn’t understand their own responsibilities for accessibility, and wrongly assumed it was “just the developer’s job”.
• Some people knew they needed to do accessibility, but they didn’t have the knowledge or the skills to do it.
• Some people had the knowledge and the skills, but they didn’t have access to the tools to be able to check their work. JAWS and Dragon were the department’s preference, but licences were difficult to obtain.
• There was a lack of trustworthy guidance. Some documentation did exist, but it was fragmented, duplicated or contradictory. There was no single source of truth.
• Implementation was inconsistent across teams, and where it was implemented, it was driven by individuals in the team who personally took on the responsibility, rather than embedded ways of working.

The three pillars

The findings showed that focusing solely on compliance was pretty much the root of the problem. The department was essentially mandating that people pass an exam, but providing no support or training around the subject. Nor was it helping teams to even understand why the exam was important in the first place.

Accessibility compliance is an outcome of a system, not a strategy in itself. The work you do, and the ethics and culture of the organisation, quietly drive compliance from the background. So, it’s important to make sure people have the right skills, knowledge, tools, and support. It’s just as important to make sure that the culture in the organisation is one that embraces this work and understands its significance.

So, my strategy was built on three pillars. I got the idea from the well-known “fire triangle”, which most of us learn in science at school. A fire needs heat, oxygen and fuel to be sustainable and keep burning. Take one away, and the fire burns out. My analogy for accessibility is very much the same. Like a fire, it needs three things to be sustainable: compliance, culture and capability. Take one of these away, and the ability of the organisation to deliver accessible services, like the fire, burns out.

Accessibility roadmap

With the gap analysis and the three pillars, it was now just a case of creating a roadmap and a backlog of work.

I started by laying out all of the obvious things which were missing that would need to be delivered, like tooling, documentation and governance. I mapped these against the three pillars. For example, tooling contributes to capability, and governance processes contribute to compliance. Some of these were also broken down into smaller, more specific deliverables, because something like “governance” is too broad.

For every piece of work I planned, or was asked to do, I would map it to these three pillars. If it didn’t contribute to any of the three Cs, then I’d argue we probably shouldn’t be doing it, because it was unlikely to help us deliver the strategy.

Once all of the deliverables were laid out and mapped against the three categories, the last step was prioritisation. Using a simple prioritisation matrix, with effort on one axis and impact on the other, I was able to identify all of the high-impact, low-effort deliverables. The goal was to work on improving things in all three categories, as quickly as possible, so the prioritisation was as follows:

• Now: High impact, low effort
• Next: High impact, high effort
• Later: Low impact, low effort

Anything which was low impact, high effort was pushed to the bottom of the backlog to be reassessed at a later date.

Result

The strategy was not just a document, it was a delivery plan. It helped me to build the foundations for sustainable accessibility in one of the government’s largest departments.

The department went from having no accessibility practice to having a full-time accessibility specialist role, with a solid career path from junior to working level, senior, lead and head of role. We also created a core team of several full-time accessibility specialists to work with the various product teams across the organisation. Product teams also started to hire their own accessibility specialists directly into their functional areas, and to bring in contractors to help with shorter-term pieces of work.

Senior leadership went from having no oversight of which of their services were in scope, compliant or carrying risk, to having a complete picture. They now had data to see problem areas, and monthly updates on progress.

The people in product teams went from having limited knowledge, skills or support, to having training, tooling, documentation and templates. We also equipped them with processes and testing procedures, which they could embed into their current ways of working, and deliver accessible services sprint after sprint.

In three years, the strategy improved the compliance of over 120 digital services, from a baseline score of 5% when I took on the role, to around 70% when I left, with most of the non-compliant risk falling on internal legacy systems which were due to be decommissioned in the following years anyway.

I also wrote up this thinking in a blog post, Defining a strategy for accessibility, which other organisations have used as a starting point for their own strategies. More recently, I revisited it for TetraLogical in Sustainable accessibility: compliance, culture, and capability.