Defining a strategy for accessibility

I've been in my role for about a year now. And, to be honest, it feels like it's been about a week.

Coming from an Interaction Design background, it's the first time I've had to step into a truly strategic role. I've gone from designing services and writing HTML to designing spreadsheets and writing emails... A lot of emails.

One thing I've found is that change in a large organisation can be relatively easy, and at the same time incredibly difficult. I guess, what I mean is, you can't just make it happen overnight.

You use agile methodologies, you do research and you adapt. You re-prioritise if the landscape changes and you aim to deliver the most value for the current situation.

However, agility is somewhat subjective.

We can all probably agree that both a chipmunk and a chimpanzee would be considered agile creatures. But their agility is not comparable. One weighs 60 grams and one weighs 60 kilograms. So, even though they're both 'agile', the fact that one is 1000 times bigger than the other means when they're moving between point A and point B and avoiding obstacles, the larger of the two is always going to change direction more slowly.

This is the issue with large organisations. They often have an unrivalled ability to gather momentum quickly, but slowing down and changing direction, despite it being quick for something so large, it is still relatively slow in comparison to smaller entities.

So, when it comes to implementing a strategy, the process takes time, and it's important to not lose faith or give up on the journey.

Framing the problem

Before you can fix a problem, you need to understand it. This was one of the first things Ben Holliday taught me when I joined Government.

If you know some services aren't meeting the standards, you need to do some research and really understand why.

I teamed up with the awesome Emma Nichol, a Senior User Researcher with an incredible eye for detail. We designed a survey and analysed responses from over 200 people.

The responses spanned all of the roles you'd expect to see in a multidisciplinary team, plus a few others:

• Product Manager
• Delivery Manager
• User Researcher
• Content Designer
• Interaction Designer
• Frontend Developer
• Software Engineer
• QA Tester
• Performance Analyst
• Business Analyst
• Other

We were looking to discover how much people really understood the laws, their responsibilities, and what it takes to make an accessible service.

We wanted to identify where the barriers or knowledge gaps were which might prevent teams from consistently delivering accessible services. We wanted to understand how we could support these teams and how we could measure accessibility compliance more accurately going forwards.

If you look across all of Government and a lot of the big organisations in the private sector, I think there's generally a pretty good awareness of accessibility now. Most people have at least heard of it, which is a good thing. But, the level of understanding varies massively from organisation to organisation, role to role and person to person.

Unfortunately, the scale of what it means to be accessible isn't always obvious.

"Accessibility... That's just, like... Screen-readers and stuff? Right?"

The problem is, digital accessibility is hard! And, ironically, the legislation and the documentation surrounding it isn't particularly accessible. It's fragmented. It's complex. It's often written in legal jargon or it's written so subjectively it's left wide-open to interpretation.

We found that generally the biggest barriers for any organisation delivering accessible services are:

• a poor understanding of accessibility and why it's important
• a lack of clear guidance or documentation
• a lack of structured training
• difficulty obtaining expensive tools such as JAWS and Dragon
• difficulty recruiting users who have impairments

The compliance conundrum

We found it's common for large organisations to focus all of their efforts on the rules. All the guidance, all the processes and all the governance, they all focus on the same thing. Compliance!

It's easy to see why a lot of organisations do this. On the surface, compliance is the obvious way to see the risks and measure the progress.

However, the problem with this is you're effectively demanding people pass an exam without really teaching them the subject matter. Mandating compliance with no focus on education is an impossible task for everybody involved. It can lead to poor performance and vanity metrics. People get things wrong, cut corners or eventually they just give up.

If you don't build the capability in house, you can pay for third party audits and you can then fix those specific problems in that moment. But, compliance is only a snap-shot in time. One iteration and your audit report is no longer comprehensive. Several iterations and it becomes almost redundant.

Your strategy needs to be sustainable. It needs to be built from the ground up, embedding accessibility into the very fabric of your organisation.

Sure, compliance is one very important part of the puzzle, but in order to be accessible you need more than that.

The 3 pillars of accessibility

I remember in school we learned about the fire-triangle. Fuel, Oxygen and heat are required to make a fire burn. If you remove any of those things from the equation, the fire will use up what it has left and eventually burn out.

We can think of accessibility in a large organisation in the same way. There are 3 core parts. Compliance, education, and culture. If you lack any of these 3 things over a sustained period of time, the strategy is unsustainable and your ability to consistently deliver accessible services will burn out.

Compliance

Compliance is checking your digital service against a defined standard or law. At the time of writing this, the standard is the Web Content Accessibility Guidelines (WCAG) 2.1 to the level of AA, and the main piece of legislation is the Public Sector Bodies Accessibility Regulations 2018.

Compliance is essential. Without it you have no way of measuring how good or bad something is. But, on its own, compliance is not enough. If you view accessibility as a checkbox exercise or a governance gateway then you're unlikely to have any truly accessible services.

Culture

Culture is embracing accessibility and embedding it in everything you do as an organisation. It's the attitudes of your colleagues and the way accessibility is viewed and talked about. It's discussions, community, inclusion. It's treating accessibility as a user-need and a basic human right, rather than a list of things to check off or a governance gateway to get through.

Having a good culture is essential. But again, on its own, it's not enough. Being passionate about accessibility it is great, and it can be infectious, but if you do not have the right education or training in place then you have no way of implementing it successfully. So, you are unlikely to have any accessible services.

Education

Education is making sure teams have the required skills to be able to deliver accessible services. It's documentation. It's training. It's knowledge.

Like the other two parts, education is essential. But, again on it's own it's not enough. You can implement training, you can give people all the skills. But if the culture is bad and people don't see the point in doing it, then you're unlikely to have any accessible services.

Building a sustainable strategy

Building a strategy around culture, compliance and education, in my opinion, is the only way to ensure all the hard work you're doing now isn't for nothing.

There are a few things you can do to make sure your organisation is set up in the right way to deliver accessible services.

Plan your future

Try to have a series of short term and long term goals. What are you working on now? And, what work do you expect to complete in the next 6 months? In 12 months? In 3 years? In 5 years?

When you map these out, really look at everything you're working on and understand how it's contributing to compliance, culture or education. And if it's not contributing to any of those things, ask yourself whether you need to work on it at all.

By mapping your aspirations to a timeline and a category, you can quickly start to spot the holes. If your entire plan for the next 3 years only has things which contribute towards compliance, perhaps you need to reprioritise. You want to have high impact things in all 3 categories for each of your timed chunks.

Guidance and training - Education

Because we found in our research that accessibility documentation is fragmented, we decided to pull it together. We called it The Accessibility Manual.

Where the guidance was difficult, we explained it, and where the guidance touched on information in other places we linked to it. The idea was to pull the Service Manual, best practice, GOV.UK guidance and legislation all into one place where people could understand it.

One of the most important parts of the manual is the fact that it breaks accessibility down into guidance for your job role, because we found that across all organisations, people are not always sure what their responsibilities are within a team.

A lot of people wrongly assume designers and developers just do the accessibility work, and that is simply not true. Everyone has a role to play, and breaking it down by job role is perhaps the most useful way we have found to help people to understand the impact they have on the accessibility of a service.

We wanted to make the manual as open as possible, so feel free to use it, and if you have any suggestions or want to contribute, you can do that too! View the accessibility manual on GitHub.

We are also working on a series of structured training courses, which we will be able to open source so other organisations can use them once we have done pilots and refined the content.

Accessibility Principles - Culture

I collaborated with Colin Oakley, and we created 5 accessibility principles. They're really design principles with a focus on accessibility, but they complement the 10 GOV.UK Design Principles and allow teams to keep accessibility at the forefront of their design all times. We tried to keep them organisation agnostic, so feel free to re-use them, or edit them to make them your own.

The 5 principles are:

1. Inclusion is better than empathy
2. Accessible design is good design
3. Start with what works
4. If it's not accessible, it's not done
5. This is still for everyone

You can read the accessibility principles in more detail in the Accessibility Manual.

Best practice - Compliance, culture and education

If you know the best steps to make things compliant. Document them and encourage teams to adopt them.

With best practice, it's best not to make it mandatory. Every team is different so they need to remain flexible, but they're always good to use a starting point.

I've found the best way to do accessibility without it being a huge bottleneck at the end is to do the technical and functional testing on each page as you build it. This way when you get to the end, you only have to do usability testing on your user-journeys, rather than having all 50 WCAG criteria to check on 40 pages as well as all the assistive technology testing.

A best practice example:

1. Include accessibility considerations in your definition of ready on your user story or task ticket. So, before you even build the feature, you've discussed it's components and understand any parts that might need more work such as type-aheads or dynamic content.
2. When you design or build any page, start with existing patterns and components in the GOV.UK Design System. If you use everything to it's specifications, it should be pretty accessible right off the bat.
3. When you're finished building the page, use a HTML validator to catch any mistakes in your code. You can use something like the HTML Checker Chrome Extension or the W3C Markup Validation Service.
4. Once your HTML is Valid, check your page using automated accessibility testing tools. A couple of good examples are Axe and Wave which can be installed as Google Chrome extensions. Not all tools are the same, so use a few. They only take seconds to run. To see what each tool can find, see the GDS accessibility tool audit.
5. Once the automated tools are passing, manually test your page against the 50 WCAG criteria. You can use something like the Accessibility Insights Chrome extension. If you select the assessment option, it will take you through all the manual checks for your page. It will also produce a HTML report which makes up part of your testing evidence.
6. Once all the automated and manual tests are passing, test your page against the functionality of different types of assistive technology. You should test it with at least one of each of the 3 main types. A screen reader, a screen magnifier and a voice controller. You should document what you tested and how it performed as part of your evidence. I've created a few assistive technology testing templates you can use: NVDA testing template, Voiceover testing template and Voice Control testing template.
7. Once your page is passing on all of these points, you're ready to push your code. You should build automated accessibility tests into your integration pipeline as a last line of defence to stop you pushing in any obvious errors. You can implement something like AxeCore or Pa11y-CI. These should reject any code pushes if they find accessibility issues.
8. Now you've pushed your page and the code is all ok, you should usability test it as part of the whole application. Use the 3 types of assistive technology testing again, but rather than using every single function on every single page, just make sure you can complete the service from the start to the end using the common features. If you've followed the previous steps for every page, there should be no issues. But sometimes when you test something in isolation you don't pick up on things like back buttons not working as expected.
9. Update your accessibility statement. Now you are sure your service is compliant, you've documented all your evidence and stored it in all the right places, make sure your accessibility statement is updated to show the dates it was last tested and the current compliance status.
10. Definition of done. If you've done all of these steps, only then consider the user story or ticket finished.

Monitoring and reporting - Compliance

Without evidence, you can't measure anything.

Create a central repository and make sure teams are regularly contributing their evidence. In order for something to be considered compliant, as the absolute bare minimum every service should have evidence to show it:

1. has no fails against against any WCAG 2.1 A or AA criteria
2. works with a screen reader
3. works with a screen magnifier
4. works with voice recognition software
5. has a valid accessibility statement

As with most things, an absence of evidence is not necessarily evidence of absence. In other words, teams may have done the work but they're just sitting on their evidence. So, it may seem unfair to badge something as non-compliant if it actually is. However, if you're struggling to coordinate the evidence collection, trust me when I say the fastest way to have people bring you their missing evidence is to publish an open report marking those teams as non-compliant.

Wrapping things up

I appreciate this is a long read, but hopefully it can help you to implement some good practices in your own accessibility strategies.

I'm not going to pretend my strategy is perfect. It's not without its challenges, but having a clear focus on improving skills, attitudes and the quality of the work is, for me, building solid foundations to deliver accessible services well into the future.

If anything in this post is unclear or you'd like me to expand upon, I'm on Twitter daily and we can pick up a conversation.

Thanks, Craig

Post details