Five things I've learned working in digital accessibility

I’ve been working in digital accessibility for around eight years now. I began my journey as a front-end developer and have since led accessibility teams and set the strategic direction for organisations around accessibility and inclusion. Here are five things I’ve learned on my journey.

Moving the needle is hard

I haven’t met anyone who wants to go out of their way to exclude disabled people. Most people want to do what is right, but the problem with most organisations I’ve worked for is that accessibility is considered too late in the product development lifecycle.

It’s often a tickbox exercise at the end of the process. Teams will build a thing, and as long as it’s WCAG compliant, it is considered accessible. When I worked at HMRC, my team began usability testing as part of the accessibility auditing process. What ended up happening is that teams would ignore the usability issues entirely.

I put this down to two reasons, we decided not to mark usability issues as must-fix and instead chose to tell teams they should fix them. Taking this approach gave teams an out. And the second reason is that usability issues often involve redesigning pages and journeys rather than minor technical fixes. Because the thing was ready for release, redesigning entire parts of a journey wasn’t possible.

Digital accessibility at scale is complicated, especially in larger organisations. This is because while you might succeed in introducing, let’s say, auditing, I have yet to work for a single organisation where it wasn’t done right at the end.

Because the audit was done right at the end, it usually means that teams will drop any fails on an accessibility report into their backlogs and hope nobody ever mentions them again.

I read something recently that said over seventy per cent of accessibility issues could be avoided in the design phase of a project. My personal opinion is that accessibility begins with user research. Getting disabled people (ones who use your product or service) involved in your research will provide infinitely more value than an audit.

So why isn’t this the standard approach? Anecdotally speaking, there are a few issues. One is culture. It is challenging to change the culture of an organisation, especially larger organisations. I’ve had great success with the culture at Monzo, but it’s a much smaller organisation. And even still, when you think you’ve cracked the culture, you’ve usually only cracked some pockets of people.

Another reason is that people don’t know enough about accessibility. People think screen readers and blind people. But it’s much more nuanced than that, and it can be overwhelming for people. Much of my role is educating people, and it’s a constant effort. The second you stop talking about accessibility is when people stop caring about it.

I also need to balance not completely overwhelming people and giving them the information they need to succeed in their roles. Give them too much, and they’ll be spooked, give them too little, and they won’t give it the respect it deserves.

If you’re walking into a role expecting to deliver transformative change, you’ll probably not get it. Get comfortable with small wins, and celebrate them when you get them. Accessibility is cross-cutting, and getting everyone bought in is nigh-on impossible.

Frustration is part of the job

The last eight years of my life have been some of the most frustrating of my career. There have been many, many days where I’ve wanted to give up. If you’re considering working as an accessibility specialist, you must have thick skin. You must also like the sound of your voice because you will say the same stuff repeatedly.

For me, this has primarily been down to where accessibility fits within the product lifecycle. If your company does it at the end, you’ll be constantly frustrated. Seeing project managers point up a ticket for a label not associated with an input as three days of work is some of the most frustrating shit I’ve ever seen.

Here are some other classics you will encounter:

• thinking you have buy-in but not actually having the buy-in.
• teams claiming to have fixed their accessibility issues, despite not fixing them at all.
• seeing the same fails over and over again.
• “But disabled people don’t use our thing.” multiple times a week.
• “We didn’t have time to make it accessible.”
• being looped in at the very last minute. Every single time. With them expecting a silver bullet.

My advice would be to focus on proactive consultancy. How soon can you get involved? The sooner, the better. I appreciate it’s not always possible to resource the level of commitment you’d need to do this successfully. Having your team available to support teams from the get-go or at regular intervals will yield much better results and hopefully reduce the amount of auditing you need.

What processes can you piggyback on? Does your org have design and content crits? Get a seat at the table. What other ceremonies can you infiltrate? Use existing processes and embed into them. I’ve had a lot of success doing this.

The perfectly accessible thing to everyone doesn’t exist

I remember when I first took an interest in accessibility. I wanted to fix everything for everyone. Who wouldn’t? It took me a few years to realise that I’d never be able to do that. The perfectly accessible thing to everyone doesn’t exist, and I’d call the person who claims their thing is fully accessible a liar. We’re always excluding someone, and you know what? That’s fine.

For me, accessibility is making things work for more people. Gareth Ford-Williams said brilliantly, “Start with who you’re willing to exclude”. Getting my head around this concept took me a while, but it works. If you’re building a bank, you can safely exclude three-year-olds. Create a list of people who you’re willing to exclude, and whatever you’re left with is who you need to make it accessible for.

The same can be said about user research. If you’re creating a terms of service page with a lot of content, you should consider researching those with ADHD or dyslexia. Who is most likely to be impacted by the thing we’re building? Focus on those people. Bringing in a token blind person who doesn’t even use your product will not give as good outcomes.

The standards and tools will only take you so far

Young, naive Shaun thought that compliance with the Web Content Accessibility Guidelines meant that the product or service was accessible. This couldn’t be further from the truth.

If you follow me on Twitter, you’ll know I speak a lot about this. WCAG is a technical standard that has somehow slid into company processes and is used to measure how accessible something is. I’m not saying WCAG is useless because it isn’t. It should be viewed as a floor, not a ceiling, to gauge accessibility.

WCAG compliance is a good start, but WCAG itself is, ironically, relatively inaccessible. It’s open to interpretation and doesn’t cover cognitive accessibility. I can develop something compliant but inaccessible very easily. I’ve said it a few times, but testing with real users will give you much better outcomes than complying with a technical standard.

The same can be said about the various automated accessibility tools. When used together, they will find around forty per cent of accessibility issues. They’re definitely useful, but you can’t automate your way to disability inclusion. Test with real users.

Burnout is real

I’m not the first to talk about burnout and accessibility. I’ve seen many others talking about it too. Craig Abbott did a brilliant podcast recently, and burnout was a topic of discussion. I have personally been burned out this year. I ended up off sick because of it. For me, burnout happened for a lot of reasons, but here are a few:

• I was a single point of contact/failure for all things accessibility for an entire organisation
• My job description covered about five different jobs
• I tried to help too many people/teams
• I was dejected because I hold myself to super high standards that I couldn’t meet because I never had time to think, let alone do my best work

Accessibility is not one person’s job, but too often, accessibility specialists are either one person or tiny teams. I’ve only ever worked at one place where there was a big accessibility team, and it worked beautifully. Recognising burnout is so important, if you’re in this line of work, please look after your mental health, it can be a tough ride.

One thing I’ve gotten better with over time is not trying to do too much. I accept I can’t do everything and be everywhere. I accept small wins, and I celebrate them when they happen. We’d all love to do more and achieve more, but ultimately it burns you out. Falling out of love with something I’m passionate about is non-negotiable to me. I was almost there, and it sucked!

Closing thoughts

This post ended up being a lot longer than I thought it would be. But I hope there are some lessons others can learn. Despite saying that working in accessibility is really frustrating, it is also the most rewarding job I’ve ever done. Seeing the penny drop is the best feeling for me. When you see people ‘get it’.

I’ve achieved a lot in the last eight years. I’m immensely proud of my work and feel privileged to have educated thousands of colleagues over this time. Seeing changes you suggest make it into production or seeing a team U-turn on a design decision is so fulfilling, knowing the impact it will have on real people.

Working in accessibility is very rewarding…once you get past all the bullshit. And don’t get me wrong, attitudes towards accessibility have improved ten-fold over the years, but it’s still vastly underfunded!