The 7 Types Of Web Accessibility Professionals

For some, they’re evolutionary stages, for others, it’s the core of their professional style…

Spending nearly half a decade in web accessibility to some extent or another, I found that as with everything, you’ll quickly notice patterns. Some of these will be closely tied to a professional’s personality, others are merely phases one goes through, so I thought it would be fun going through them all. Maybe you’ll recognise yourself or someone else. 😉

Before jumping into the seven types, I want to make something clear. Whether you recognise yourself or someone else in this list, ultimately it doesn’t matter too much. You are doing a good thing. Perhaps your methods need polishing, perhaps you’re going about it in a somewhat misguided way, but ultimately, it’s coming from a good place. The rest is… evolution. The evolution of you, your skills, and the surrounding professionals.

The angry finger-pointer

They take every accessibility mistake as a personal attack. Will go out of their way to tell people off in public and in private, will resort to insults if necessary. This won’t get them many friends and may even work against their objective to make the web a better place for everyone.

They are also known to complain incessantly and spend more of their time explaining how terrible a website is, instead of educating and helping fix the issues. Constructive criticism isn’t their strong-suite, and thus they’ll often find themselves in “pissing against the wind” situations which they themselves were the architects of.

While this can genuinely be a professional — though borderline unprofessional — style, I see it frequently also as a stage in someone who recently got a decent understanding of web accessibility and through that sudden enlightenment now gets angry at every injustice, just like a newly turned vegan extremist.

The idealist perfectionist

Still thinks there is such a thing as a 100% accessible web application. Completely unrealistic, does not see the bigger picture, and will always find a way to fail a website in an accessibility audit. For them, even a WCAG 2.1 AAA adherence is “the bare minimum” and damn cost, damn everything, damn launching the product, not until everyone bent over backwards, the product launch was delayed twice, and the company sees accessibility as a huge cost.

It’s important to remind every accessibility professional, that even IAAP and in general, the W3C and the law recognises that perfect accessibility does not exist yet on the web. Heck, there are even a few HTML elements that aren’t accessible. There are reasons why these are deprecated. One of them is lack of accessibility.

The theoretical scientist

Knows all the theory, but fails miserably in real-world scenarios. This one reminds me of expensive consultants who sit in on meetings and talk a good game, but crap themselves the moment they have to implement any of it.

While it’s fine to be an expert in the theoretical aspects of web accessibility, it’s a lot less fine when a software engineer lacks the practical expertise. As I have highlighted this before, web accessibility engineers are actually expected to be proficient in a ton of technologies and work with anywhere from bog-standard to borderline exotic codebases.

The dangerously overconfident

Have you ever met an accessibility engineer who added tab index to every HTML tag? Yeah, they exist! They’ll also add alt text to every image, even those that don’t need them. There are also the ones who discovered ARIA and now litter the code with ARIA properties, many conflicting each other.

They think they know everything so well, they’ll even find issues where there aren’t any just to show off their “skills”. Don’t get me wrong, they’re definitely on the right path, but doing a Udacity accessibility course doesn’t make anyone an expert. It’s merely a good starting-point. Sure, adding tab-index can get focus on an element, but do all elements require it?

Let’s also not forget how dangerous using ARIA can be. The first rule of ARIA is not to use ARIA properties. I wonder why… 😆

The reductionist

They’ll only want HTML and nothing more — the designer’s nightmare. They’ll happily turn a dynamic web app into a single-colour static site just to ensure 100% accessibility. React, Angular, Bootstrap, Material UI, Radix, Vue, anything other than vanilla HTML and CSS in their book is an abomination.

They won’t care about business needs, UX, bells and whistles, competitive advantage in the market. Nothing matters. If it’s on the web, it must be HTML or else they walk… either out the door or all over you and your designs and components. It depends on whether you’re lucky or not.

The evangelist

They’re interesting, and they genuinely come from a good place. However, there’s a place and time for everything. They don’t recognise that, though. No matter what the meeting is about, they’ll bring up accessibility and bore everyone to death with their sermon on equitable use, which they will go into great detail even if it means hijacking the entire meeting. We get it, mate, but you know, this meeting was about penetration testing a Scala service. 🙄

Don’t be that person. Seriously. Everyone gets it that you care, and likely half the room cares too, but if they see you as the person who keeps derailing meetings with accessibility, next time when it might actually matter, they won’t invite you, and you’ll have done more damage than good. Forget your reputation, you’re actually harming customers who might now end up with a sub-par product.

The speculator

They can feel a tad slimy. They know accessibility, but will always do just the bare minimum to ensure the product can’t be brought into court for not adhering to WCAG guidelines. The typical corporate defence lawyer type who only learns accessibility to know how to find loopholes, shortcuts to ticking boxes.

Because that’s what it really comes down to them. It’s not about disabled people, heck, it’s not about people, period. It’s about risk management. If the site is technically usable, it doesn’t matter that it’s a pain to use, the auditor can’t fail it because “everything checks out”. Yes, but even in pure HTML I can write a site that passes accessibility, while it’s absolutely not. Certainly, not from a usability and ethics perspective.

So, what should you be?

That would probably be the wrong question. I think a seasoned accessibility professional will inevitably go through some of these as phases throughout their career. However, after a few years, they’ll likely — or better said — hopefully find themselves using these types more as just tools.

Every so often, you really need to be the asshole in the room, to raise awareness. But that can’t be your identity.

It’s OK to call a website shite, but only as long as you don’t stop there. You go ahead and not only explain how it’s supposed to be done, but offer to help too. Don’t be the arrogant theoretical scientist, who then runs away from any responsibility of hands-on help.

Of course, because there is no perfect accessibility, you’ll frequently find yourself having to make the hard call where you stop perfecting. That’s when real expertise kicks in, helping you make the distinction between tick-box exercises and going the extra mile. And by doing that, don’t misunderstand that bringing up accessibility at your colleague’s birthday celebration is a fit topic. Read the room, and if you can’t, ask if it’s a topic that people are happy to discuss then and there.

Be the accessibility professional that actually gets shit done for all 7.9 billion people out there. If you manage to do that, you’re definitely doing something right.

A couple more articles about accessibility…

Attila Vago — Software Engineer improving the world one line of code at a time. Cool nerd since forever, writer of codes and blogs. Web accessibility advocate, Lego fan, vinyl record collector. Loves craft beer!