The first accessibility bug landed in my inbox quite some time ago. We had no accessibility specialists on the team, and I was the only one that had any sort of interest to pursue this. I had no choice but to figure it out. I had to design the solution, write up the code, test the fix and then train others to make sure it doesn't happen again.
When I first started in accessibility, I had to wear all those hats. I was the designer, the developer, the tester, the trainer, the advocate, the lawyer. Everything the team needed.
That was the period of my career with the biggest growth, or at least what felt like the biggest growth. That's because I was going from knowing nothing to knowing enough to make a real difference, I think. But it was also because I learned a lot during those initial years.
I sometimes miss those early days. Now I think I understand why that felt like one huge continuous growth period. It was because I was accumulating lots of superficial knowledge in a lot of different but interconnected areas. The problem was I wasn't going deep into anything really. There was no mastery to speak of, yet.
As I grew, I saw myself focusing more and more on the process and not so much on the minutia of it all. How to embed accessibility at the different software development stages captured my attention.
What does mastery look like?
It's understanding that each organisation's development process has its own unique constraints. It's knowing where to place accessibility checkpoints for maximum impact with minimum friction. Mastery means being able to look at a team's planning process and identify the moments where accessibility requirements should be injected so they don't lead to costly rework.
It's about crafting accessibility acceptance criteria that are clear enough for developers to implement and specific enough for QA to test. It's recognising when automated testing will suffice and when human judgment is crucial.
Perhaps more importantly, it's about understanding the human dynamics of change management. How do you gradually shift an organisation's culture from treating accessibility as a checkbox to embracing it as a core value? This kind of mastery comes from seeing patterns across different teams and projects, from learning which interventions work in which contexts and from developing an intuition for when to push for change and when to build allies first.
I don't think I'm at this level yet. But I'm learning.
That being said, I still find myself wearing those different hats from the early days. The designer, the developer, the tester, the trainer, the advocate and the lawyer. But I try not to do it all at once. Maybe that's the key. If you want to master something, spend the time and go deep into that one area at the expense of all others.