I’m Alistair Duggin, Head of Accessibility here at Government Digital Service. I’ve been here for just over 7 months now. My job is to make sure that GOV.UK is as accessible as possible. This means that we are not excluding people on the basis of a disability, as I explained in my recent post - What we mean when we talk about accessibility.
My background is as a developer. I’ve worked on lots of large projects including the BBC London Olympics 2012, BBC Weather App, The Money Advice Service and Pension Wise. I’ve experienced first-hand how hard it can be to make products and services accessible and the many challenges that teams face.
My ultimate goal is to make GOV.UK accessible to everyone. To do this we need to raise awareness of accessibility and make it easier for people to make things accessible.
The accessibility of GOV.UK is good compared to many websites. But there is much more to do. I want to make it an exemplar for accessibility that others can learn from and help improve accessibility of the web in general. A big ambition, but I believe there is nowhere better to do this than at GDS.
One of the biggest challenges is the sheer size of GOV.UK, the number of people contributing to it, and the fact that people work on it all around the country. GOV.UK is not a single website. It is made up of many parts.
There is the publishing platform used by all government departments and agencies to publish over 300,000 pages of content by over 3000 people.
There are over 800 digital services that allow people to register to vote, claim a benefit, renew a licence and calculate taxes etc.
There are the public facing parts of GOV.UK as well as the internal systems that people use.
Furthermore, government services are not just online. They have non-digital aspects like letters, call centres, face to face. These must all not exclude people on the basis of a disability such as a visual, hearing, cognitive, or motor impairment.
The common approach to accessibility
The way accessibility is usually approached is to set a policy that is based on meeting a technical standard, the Web Content Accessibility Guidelines (WCAG) 2.0 to level AA.
Designer and developers are told to adhere to an accessibility checklist and once the website is built it is evaluated for accessibility by a specialist. Occasionally usability testing with people with disabilities is also performed at this time. A report listing all the accessibility issues is provided. The designers and developers are told to fix them, often with no support and little background knowledge.
As a result, accessibility can be seen as a burden and a constraint to creativity and innovation. Fixing bugs late in the development cycles is always much more difficult than doing it early so accessibility is also seen as expensive.
Due to people having a low awareness of the issues that people with disabilities can face when using a service and due to people being overwhelmed by how complicated accessibility can be, it is often ignored or not given the priority it requires.
Accessibility is not just about meeting a standard
The goal of accessibility is not to meet a standard, it is to make sure the people with disabilities can use your service as easily as people without a disability. It is unlikely that someone will complain that a service doesn’t meet a standard. They will complain that they are unable to do what they need to.
Following a technical standard is an important aspect of making something accessible, but it does not ensure that what you have made is accessible. A standard is a tool that helps you get there more efficiently. But you also need to understand how people with disabilities will use your service and include them in the design and testing of it. This is all too rarely done.
A better approach to accessibility
A better approach is to help people understand that making a service easy to use for people with disabilities makes it easier to use for everyone. Accessible design is good design. Designing for disability leads to innovation. When you get feedback from people with disabilities early in the design and build of a website or service problems become easier to fix, and you come up with solutions that benefit everyone.
When you provide support for how to approach accessibility and how to solve issues, accessibility becomes easy. It is under these conditions that people are much more likely to embrace accessibility with open arms.
This means raising people’s awareness of accessibility and growing a community where people with little or no accessibility experience can get support from those with more experience. It also means providing guidance and solutions for common accessibility issues.
We want a culture of designing with accessibility in mind, where services are made accessible by default.
We need more than an accessibility team to do this. We need an army of people across government that care about accessibility, who reap the rewards of building accessible services and sharing solutions.
One of the GDS design principles is 'do the hard work to make it simple'. This is how we need to approach accessibility. We need to build a team that can help make it simple rather than building a team that just tells people they are doing it wrong.
We need to reduce the duplication of effort that is happening and instead utilise this effort to establish best practice and reusable patterns and solutions so accessibility becomes easy and efficient.
This is what we are starting to do at GDS.
The story so far
So what have I been up to for the last 7 months?
I’ve been doing a lot of traveling around the country. Going to departments and meeting teams that are building new digital services. Doing lots of presentations to raise awareness of accessibility and trying to inspire people to take up the challenge of making their services accessible. Talking to people to find out who has already been doing this. Seeing how teams are approaching accessibility. Identifying the challenges that teams are facing. Thinking about how we can make it easier.
We’ve been recruiting for people to join the GDS Accessibility Team. Ensuring that we have the right skills and experience to deliver accessibility support efficiently and effectively across government.
We’ve been building an army. A couple of weeks ago we started a cross-government accessibility community. An email list where people can ask questions, share information and provide support to others.
We started by inviting the people I had met in government that are already doing great accessibility work. Those that are enthusiastic and have experience and knowledge to share. We then opened it up to everyone in government. We already have over 200 people, from a range of departments, with people working in content, design, development, user research and quality assurance.
We also have a number of people with access needs who are keen to share first-hand experiences. We have our first accessibility meetup on May 19th. All 65 places went within 18 hours. We’ve been blown away by the response.
Twelve(ish) things for the next 12(ish) months ... in no particular order
One of my priorities is to continue to raise awareness, inspire people and get them to join and participate in the community. If people don’t care and don’t get support, then they will only do the bare minimum of what is required to make something ‘accessible’.
Improving how teams approach accessibility is another priority. They need to understand access needs early in a project. Get feedback from people with disabilities as part of regular user research sessions. Run automatic tools to identify and prevent common accessibility issues.
By providing accessible versions of all of the common building blocks that teams use to provide online services we can remove many of the problems that teams face.
By providing guidance on how to test services we can help teams to do this early and often rather than relying on external specialists at the end of the build.
We need to know what technologies people are using to overcome their disabilities so we can ensure our services work with them. We’ve launched an assistive technology survey to help us do this.
We also need to make it easier for teams to set up and use assistive technologies.
We’re planning to research access needs that are common to all services. Do people who struggle to see or process text need to be able to change the colours and typography on GOV.UK or have the content read out to them? What is the best way to support deaf people whose first language is British Sign Language and find English hard to read and write?
Can we make it difficult to publish content that has accessibility issues? Things like missing alternative text, headings that do not follow a hierarchical structure, videos that are missing captions and transcripts and PDFs that are not tagged or only contain an image.
How do we make it easy for teams to find people with disabilities to take part in usability testing and provide input and feedback on the design and implementation of services?
We need to make service assessments more rigorous to reduce that chance of people being excluded from being able to successfully use a service.
We need to work out the best way to monitor services that are live, so the accessibility of them is prevented from declining as new features are added.
And one for luck ...
We need to make sure that when services are procured that high accessibility standards are maintained. Both the provider and the buyer must be aware of their responsibility.
There is a lot to do. But, by working together, by making accessibility easier and by making it part of the culture, we can do it. We can transform government and influence the rest of the world.