Lately I've been volunteering for a charity that is building a website from scratch. I'm not actually doing the development (it's a wordpress website and another company is building it) so I'm acting in more of an advisory role and doing things a bit outside of my comfort zone that I don't normally get to do in my day job.

As part of this I did a review of the website's accessibility, and I want to write down how I approached this.

Why focus on accessibility?

I suggested an accessibility review because I thought doing this was the best way for me to add the most value to the project at this stage of the development, since it would surface lots of easy to fix problems with the user experience of the website.

It's very easy to underestimate the impact of accessibility, but looking into the demographics of your users can be very eye opening. For example, in the UK 19% of working age adults have a disability and 45% of pension age adults are disabled. 1 in 12 men are red-green colour blind, and it's also thought that up to 10% of people have some form of dyslexia.

Accessibility doesn't just affect the permanently disabled. Impairments can be temporary (like a broken arm) or situational (like glare on a screen making things harder to read, or being in a noisy environment). So focusing on this stuff makes websites easier to use for a wide range of users and situations.

If I haven't convinced you that accessibility is important, I strongly recommend reading this blog post by Sami Keijonen: Building an Inclusive Web: Why Accessibility Matters.

How to start

This project was quite daunting for me as I don't do a lot of frontend work in my day job.

Since I work in the public sector (where accessibility is very important), I was aware of common accessibility issues, but I'd never done a systematic review of a website that someone else has built. It's a ton of work that I didn't fully appreciate when I first suggested it. So my imposter syndrome kicked in and I wasn't sure how I was going to actually do it.

I got past this by seeking advice from my coworker (who actually does this as her job). She gave me a lot of good feedback and shared some useful resources.

I ended up basing my review around some guidance from the UK Government Digital Service: Doing a basic accessibility check if you cannot do a detailed one. You could also use 18f's accessibility checklist or Handling common accessilibity problems from Mozilla. All of these guides explain practical things you can do to improve website accessibility without being an expert.

Choosing a sample

Before I could start the review, I had to work out which pages I wanted to check. The website I was working with was quite small, but I decided to focus on 14 specific pages. The smaller the sample, the better, because the more pages you look at the longer the review will take and the more repetitive the work is.

I chose these pages based on a couple of considerations. Firstly, I wanted to include pages that were on the critical path for an important user journey, like registering as a new user. I also looked out for pages with unique components or interactions not found elsewhere.

In my case there was a lot of different UI elements because the website uses a lot of different wordpress plugins, so even though some parts were very accessible, others had a lot of issues.

Linking each check to the WCAG criteria

Before I started checking stuff, I spent a while going through the Web Content Accessibility Guidelines (WCAG). WCAG classifies accessibility criteria into 4 areas (accessible content should be perceivable, operable, understandable, and robust) and 3 levels (A, AA, and AAA). Since my review wasn't a thorough one, I just looked at the A and AA criteria and skipped the AAA ones.

I went through each criterion and identified the checks I was doing that most closely related to it. This allowed me to refer back to the WCAG while I was doing the review, to better understand the impact of the problems I'd identified and how to fix them.

The WCAG uses quite precise and technical language, so I also used the GDS WCAG 2.1 Primer to understand the criteria better.

Presenting my findings

I used a spreadsheet to note down findings as I went along, but because I wasn't able to fix everything myself, I needed to be able to explain to the developers what was wrong and why it matters. As I'm not working with them directly, I put everything in a written report with a section for each of the checks.

For each thing I checked I created a table that looked a bit like this:

I separated out the findings from my suggestions on how to fix it, because I wanted to be clear about what the actual problems were, and make it easy to transfer them into a ticketing system. Wherever I had to describe a particular area of the website, I also included screenshots to show exactly what I was looking at, to avoid the potential for miscommunication.

I added a blurb at the beginning explaining how I'd carried out the review, and I also included a glossary of terms, which is mostly lifted from WCAG itself:

Structuring the report like this made it much easier to clearly and concisely explain the problems, without assuming that the reader is already knowledgable about accessibility.

To be continued?

I've now finished the review, and I'm waiting to hear back from the developers 🤞

Although I spent a lot more time on this than I planned, I learned a lot from doing it, and it actually made me interested in doing more frontend development(!)

If you work on a team where accessibility isn't already embedded into the design process, I would really recommend doing a review like this yourself. It doesn't have to be exhaustive - just shining some light on where you are falling short is better than doing nothing.