How to start a career in accessibility (Part 2 of 7)
Part 2 of a 7 part series: How to get started
A guide on how to actually get started in a career in digital accessibility.
Accessibility TestingVocation
I'm really glad you've decided to read part 2 of this series in getting your career started in accessibility. It's been a long and rewarding career for me and I think that this role is maturing into something very special.
Part 1 was the pep talk. This Part 2 is more is practical: what you need to know, what kit you need and what to do before someone will pay you to test for accessibility.
Learn the domain
Start with how each WCAG criterion affects real people. Everything else follows from that.
The guidelines can be a shock, especially if you’ve never written code. They’re made up of dozens of success criteria, each covering one specific part of design or development, and they’re written in very technical language. When I first got into accessibility I had little idea what most of them were trying to say. Frankly, I think the language puts a lot of people off the industry before they’ve started. Learning them takes patience.
We knew about that learning curve when we built Labrador, our testing tool, so we wrote all the guidance in plain English. Once you know that “non-text content” usually means images and “time-based media” usually means video and audio, most of it starts to make sense.
There are a few ways to learn WCAG today. You can book a course. You can ask an AI tool (if you’re happy using one) for a plain-language version of each criterion and an example of where it applies. Or you can run a test in Labrador, which explains each criterion as you go.
Beyond the standards, follow people. LinkedIn is where most of the accessibility crowd hangs out, for better or worse, and Reddit and Slack both have busy communities too. Aim for a feed that mixes practitioners, disabled people writing about their own experience, and the odd lawyer posting about the latest lawsuit. Six months of that will teach you more than any course.
A word of caution. The accessibility community online is mostly brilliant, but some people in it mistake being loud for being right. You’ll work out who’s who soon enough. Follow the ones who teach; mute the ones who shout.
Learn some HTML (and then some more)
You don’t need to be a developer to work in accessibility. You do need to be able to read code and understand what it’s meant to be doing, and the more you can read, the better you’ll be at the job.
HTML is the baseline. Know what most of the tags do. Understand why a <div> tells a screen reader nothing and a <button> tells it everything it needs. Learn the landmark elements and what they give screen reader users (a way to jump straight to the navigation or the main content). Learn enough to open a page’s source and spot when someone has built the whole interface out of divs and spans, because they almost certainly have.
Then ARIA. Here’s the most useful thing anyone has ever taught me about it: ARIA can fix almost anything, and you should avoid it wherever you can. Native HTML does the job for free. ARIA is for when HTML alone can’t do it, and there are plenty of reasons that happens. If you learn one rule, learn that one. It’ll save you a hundred audits’ worth of arguments.
After HTML and ARIA, get to know how developers work. You don’t need to write React, but you should know roughly what React is, what a component is and what a build step does. Have an idea of how Agile teams plan their work, and why the engineer you’re talking to pulls a face when you ask them to change the colour of a button. Accessibility work happens inside engineering teams. The better you understand how those teams operate, the more useful you’ll be, and the harder you’ll be to dismiss.
Kit yourself out
You can’t test for accessibility without the right kit, but when you’re starting out it’s all free. You need a half-decent laptop and the following.
A screen reader
Start with NVDA. It’s free, fully featured and runs on Windows, and in my experience it gives a more honest picture of what a screen reader is doing than some of the expensive paid alternatives such as JAWS.
VoiceOver is built into macOS and iOS, and you’ll want to know your way around it too. You might be surprised that most accessibility specialists don’t do their main screen reader testing on a Mac. That’s because only about 9% of screen reader users use one. I also find VoiceOver on the Mac miserable to test with, though I struggle to say exactly why. If you don’t have a Mac, don’t worry; you can buy one later.
JAWS is the standard in a lot of enterprise settings, so download the demo and get to know it. It’s handy as a second opinion when NVDA does something odd. One caveat: the demo’s licence may not cover commercial use, so check the terms before you bill anyone for time you’ve spent in it.
Whatever combination you end up with, learn at least two. They behave differently, and part of your job is telling which bugs are in the website and which are the screen reader being weird.
A browser extension or two
You probably know this already, but automated tools like these extensions only catch around 30–40% of accessibility issues, and they get things wrong, particularly colour contrast. Once your automated checks are done, 60–70% of the work is still left to do by hand.
WAVE
WebAIM’s WAVE is a good place to start. It gives you a lot of information and makes it easy to see where each issue comes from. It is a lot of information at once, though, which can be overwhelming if you only want to check the text alternatives on a few images.
ARC Toolkit
I’ve come to love TPGi’s ARC Toolkit. For some reason I’d overlooked it, then last year I compared a range of paid and free tools and it came out on top: it correctly picked up more issues than anything else in the test. For automated testing I now think it’s the best tool available.
The browser’s own dev tools
Learn the accessibility panel in Chrome or Firefox. It’s free and powerful, and most people ignore it. Learn to edit the HTML in the dev tools too, so you can see how a change to the markup improves (or wrecks) the experience for someone using assistive technology.
Devices
Ideally, test on more than one. Windows and Mac behave differently, and so do iOS and Android. A bug that’s catastrophic on one platform might not exist on another. If you can only afford one setup to begin with, I’d go for Windows with Chrome and NVDA, and learn the screen reader on whatever phone you already have.
Time with real screen reader users
One last thing on screen readers. The most useful thing you can do is watch someone who uses a screen reader every day use the thing you’re testing. Twenty minutes of that will teach you more than twenty hours in NVDA on your own.
Think about how you arrange it. If you’re volunteering and someone’s happy to give their time alongside you, brilliant: that’s a fair exchange, and plenty of people are willing. If you’re being paid for the audit, the person helping you should be paid too. Disabled people who do this professionally are specialists, and their time is worth money in the same way yours is. Know which situation you’re in and act accordingly.
A way to record and store results
This is what we built Labrador for: making the kind of audit I’ve just described less of a slog. It’s a guided WCAG testing tool written in plain language. It walks you through the checks, helps you record evidence as you go, keeps your scope straight, and at the end turns everything into a report that doesn’t look like it was written at 2am the night before delivery (even if it was). It’s aimed at exactly the person reading this article: someone new enough that the blank page of “where do I even start with this audit?” is the scariest part of the job.
It won’t make you a great accessibility tester. Only practice does that. It will get you practising the right things sooner. Have a poke around if any of that sounds useful.
There’s also a free version, which is perfect for getting started. Sam and I want to support people who are new to accessibility testing as much as we can.
Go to testwithlabrador.com. You’ll love it.
Ok, gratuitous product plug over, back to the advice...
On qualifications
I don’t have any formal accessibility qualifications. When I started in this industry there weren’t any. I’ve never taken the CPACC or the WAS, and I probably never will. Sam, Labrador’s co-founder, has the CPACC and may see this differently, but here’s what I think.
This next bit is controversial, so get a second or third opinion (or ask Sam).
People I know who’ve taken the IAAP exams, one of them blind, tell me the exams are often inaccessible themselves (a whole other conversation), that a lot of the content doesn’t reflect modern practice, and that the learning adds little if you’ve been doing the work for a while. So why get one?
The best reason is that there isn’t much else. If you’re serious about getting into the field, the IAAP certifications are the obvious place to start, and I salute you for it.
The other reason is bots. Recruitment software filters CVs before a human ever sees them. A CPACC after your name gets you past the filter; twenty-plus years of experience might not. I’m honestly not sure I’d make it through the recruitment funnel at a big company today. Thankfully there are specialist agencies, such as PCR Digital, that match accessibility skills to the right work. If I ever wonder what to do with myself, that’s where I’d go.
So here’s my take. If you’re new and you need to prove to a recruitment system that you’re serious, get the qualification. It sounds harsh, but I see it as a tax you pay to get through the door. It says very little about whether you can do the work. Pay it if you need to, and don’t confuse having the letters with having the skill. The skill comes from doing the work.
If you’re moving into accessibility through an employer who already knows you, a specialist recruiter or a network that can vouch for you, you can probably skip it.
Your first piece of work
At some point the learning has to turn into work. This is where most people get stuck.
One thing I can almost guarantee: your first audit will be bad.
Mine were, as I said in Part 1. You’ll miss things. You’ll flag things that aren’t issues. Your tone will be off, either too soft to land or too militant to be useful. It’ll take you three times as long as it would a year from now and be half as good.
That’s fine. A first audit only has to be finished, so you can do a second one. If you’re brave enough and lucky enough to have a mentor, ask them to review it.
Here’s what your first audit needs:
Start with a clear scope. Which pages, flows and platforms did you test, and with which assistive technology and browsers? Without a scope an audit is just an opinion, and later on nobody can tell what you looked at.
Every issue needs evidence: the page, the element, what you did, what happened, what should have happened, and which WCAG criterion it fails. Screenshots or video clips are essential.
Give each issue a severity. A missing alt attribute on a decorative image is nowhere near as serious as a form that can’t be submitted with a keyboard, and your report should make the difference obvious at a glance.
Suggest a fix, or at least a direction. “This is broken” is half an audit. “This is broken, here’s the WCAG reference, and here’s roughly how to fix it” is a whole one.
Write like a human. Your readers are a developer with deadlines, a product manager under pressure and a stakeholder who probably doesn’t know what a screen reader is. Explain things, skip the lecture, and shorten their learning curve wherever you can.
So how do you get that first piece of work? A few routes:
- Volunteer. Charities, small non-profits and community groups often need accessibility help and can rarely pay for it. You get real work on a real site, and they get a better site.
- Audit your employer’s site, even if it isn’t your job. Write it up as a report and send it to someone. The worst that happens is they ignore it. At best, you’ve invented yourself a new role.
- Join the mentorship programme I’m building. Part of the plan is matching new people with small pieces of real work, some paid and some voluntary, so your first audit isn’t a hypothetical exercise. Get in touch if you’re interested.
You won’t feel ready
To be more precise, you won’t feel completely ready, and for a lot of people, the feeling of “I’m qualified to do this now” never arrives. There is a lot of Imposter Syndrome in our industry.
What arrives instead, if you keep going, is evidence. A piece of work you finished. A client who came back. A developer who said thanks. A report that made something better. Your confidence builds from that pile of finished work, and you’ll notice you know things you could only have learnt by doing the job.
So if you’re reading this and thinking there’s too much to learn before you can start, turn that round: you learn by starting. Everything in this article is a map of what you’ll pick up once you’re already working. You don’t have to tick it all off before you’re allowed in.
Find the smallest real piece of work you can. Do it. Do it badly. Do it again.
Where next
The next article goes deep on the thing now in front of you: your first audit. What goes in it, what to leave out, how to avoid sounding like you’re telling everyone off, and how to write a report people actually act on.
See you there.