At the beginning of last year, I started a new role as an accessibility-focused frontend engineer. Tech accessibility (or a11y for short) became my dream career while studying that field during the pandemic and also talking to accessibility professionals on social media.
In particular, a11y drew me in as I learned how designing with a11y in mind doesn't only help disabled and neurodivergent people, but in fact regularly leads to tech that makes everyone's lives better. One of the most popular examples of that is how a lot of the early motivation for inventing the typewriter was to facilitate writing for people who are blind and low-vision, and now we're all typing! Likewise, by designing a web app to keyboard-operable, in addition to being usable for someone with motor disabilities that make using a mouse difficult, that also benefits power-users who love a good keyboard shortcut.
But one of the biggest surprises as I got onboarded to the job and as I started going to a11y conferences, was how the skills that I use as an accessibility professional, are almost exactly the same ones I had cultivated toward what my dream career previously was: Developer Relations (devrel).
Accessibility and developer relations are surprisingly similar fields of tech; just about any skill that helps a developer advocate thrive, can also be applied in an accessibility role! To see what I mean, let's take a look at a few of my favorite similarities between a11y and devrel. If you're in, or interested in, either devrel or accessibility, this post is for you!
Community building
What made me want to be a developer advocate in 2017 wasn't just the romanticized parts about globe-trotting between conferences (but let's be real, that didn't hurt). More than that, it was how much of devrel work is centered around building a supportive community. And as I got interested in accessibility, I quickly found out a11y is also somewhere community-builders really shine.
A successful devrel program is one that not only helps people solve problems with your tech, it also creates a community around that technology. That goes from holding workshops, to explaining concepts that are new for nearly everyone (particularly true in fast-changing fields like AI and agents!), to writing well-maintained API documentation, to artwork that brings your programming language to life with a silly cartoon mascot that everyone loves to draw their own versions of. All of that both helps developers solve their problems with your tech, and gets them excited for whatever you and your team are building next.
Accessibility is just as much about community as devrel is. One of the first things you hear about as you start participating in accessibility discourse, is about just how interdisciplinary the field is. Just about every role in a company, from UX design, to UI engineering, to product management, to customer support, to documentation writing, all the way up to the C-suite, has a role to play in making a product accessible. A winning accessibility program is less a single team, and more a community that spans many different teams and roles.
In both fields, part of that community building is encouraging contributions from your community. The best devrel professionals make people feel appreciated for things like contributing to their open source projects and inviting their friends to the community. Similarly, the best accessibility professionals are great at showing people from different roles what exactly they can do from their own role to prevent accessibility issues and build accessible products.
So whether accessibility or devrel is your thing, any community-building skills you've got or you're honing will help you do impactful work.
Communication
At the center of community building for both devrel and a11y professionals, is being a great communicator, both within your own team, and with people who might have very different context, expertise, and priorities from your own role, both within your company and with customers.
A developer advocate might on one day be working with their teammates to build a demo app in their framework with realistic examples. Or be writing a tutorial to highlight exactly how to solve problems with it. Or on another day they might be hearing about pain points customers are having with using that tool, and then integrating that feedback into features for the tool they're building or into more robust documentation.
Similarly, accessibility work on some days might be reviewing designs and prototypes to distill accessibility requirements alongside designers. On other days it might be translating that to code requirements for engineering teammates. It can be evaluating accessibility tools to figure out their strengths and limitations so they know which problems a tool does or doesn't solve, and then sharing a write-up about that with stakeholders. Or it might be testing a web app for accessibility bugs and writing the results of that in enough detail for a bug report to be actionable.
Just about any communication skill can be either a devrel or an a11y skill, whether that's writing, giving tech talks, drawing diagrams, or talking to customers. So if you're interested in either field, keep growing as a communicator.
By the way, although both accessibility and developer relations are "people jobs", you don't have to be an extrovert to be a "people person". Many talented communicators in both fields are introverts. What matters more than which social style you have, is knowing how to meet people where they are.
Meeting people where they are
If you've ever coded in a community where even as a newcomer, you felt supported and could ask a question without feeling talked down to when someone answers it, that's a prime example of the impact of meeting people where they are in devrel. In fact it's precisely why the really supportive Go community is where I fell in love with devrel! Both within and outside of devrel, the Gophers are a community where there's no "noob questions".
Likewise, meeting people where they are is a critical accessibility skill because of how integral it is to cross-role coordination. People in different roles have different problems they are trying to solve, use different terminologies, and even people within the same role can have very different accessibility skill sets. Someone might have a strong grasp of color contrast but be new to screen reader testing, for example. They might have learned about designing their animations to prevent seizures, while being new to understanding how to design an app's layout to make it intuitive for autistic people to navigate, which is a conversation where the best-practices are still emerging.
And when it comes to meeting people where they are, that "where they are" can sometimes be in a stressful, frustrating place. A developer advocate who can write clear documentation with real-world examples, is a lifesaver for someone onboarding to a framework while they're on a tight deadline. Likewise, the amount of work to get a product accessible, often with having to learn new skills for the first time, can be really demoralizing. So if you can take the lead with ideas of what someone in another role might do first to solve an accessibility problem, that gives your teammates some momentum and problem-solving intuition to work with.
That is why emotional intelligence travels well between both fields. While that's often called a "soft skill", I prefer the term April Wensel uses, "catalytic skills". Both in a11y and devrel, if you can teach from where people are, in different roles or different learning styles, you're catalyzing someone else's success!
Sense of fun
Finally, accessibility and devrel are both great fields to bring your sense of fun to. As I mentioned, community-building is at the core of both successful a11y programs and successful devrel programs. A significant aspect of that, is helping people see themselves as part of the community you're helping to build. And making the community fun to participate in goes a long way on giving that welcoming feeling!
In devrel, probably the most saliently-recognizable example of that to someone outside the field, would be the stickers and swag that developer advocates give out at tech events. But there's also a lot of intangible ways to make a tech community fun that are just as important. One of the best pieces of advice on tech public speaking that I've gotten, from a video by the founder of #CodeNewbie Saron Yitbarek, was about how the secret to an engaging, memorable talk is to approach it from the perspective of storytelling, rather than a college lecture.
The #CodeNewbie community itself, by the way, is an excellent example of both fun and supportiveness in devrel, facilitating a lot of great conversations with people studying and working in every field of tech. Just as the Gophers got me interested in devrel, talking to a11y professionals on the #CodeNewbie chats helped sow my interest in accessibility!
On accessibility, a sense of fun likewise inspires both curiosity about a11y in general, and the curiosity that leads to great innovations. For example, at the last CSUN Assistive Tech conference, my favorite talk outside of my job, was about making computer games that are entirely audio-based. That was my first time hearing about audio gaming, and it made me curious both about trying those games myself, and about how else that technology can be used to create web experiences that feel lively whether you're sighted or blind/low-vision. I also lately have been thinking that a game around screen reader and keyboard navigation could help get more developers familiar with both those modes of navigation.
I hope this post showed you how accessibility and devrel are two peas in a pod. Now I'd love to know, what similarities between a11y and devrel do you see? Or if you're a career-changer into either of those fields, what similarities do you see between a11y/devrel and your old field?
Top comments (0)