Sometimes working with a larger team means that you’ll get more varied opinions about how something should be done. Now, this is good when the final result is one that covers more gaps and includes more use cases. But what about accessibility? WCAG is the conformance standard, but it’s the bare minimum. Specifications can be confusing or interpreted differently depending on your background. Teams have a lot of challenges, and accessibility is one of the big ones.

Types of Teams

In nearly 30 years of writing code for the web, I’ve been on a lot of different kinds of teams. Accessibility also carries a lot more emotional labor because it forces us to consider more user experiences than just…well, for many, just our own. High-speed internet, a really fast MacBook Pro, beautiful displays and the feeling of being nearly superhuman because people need features and gosh darn it, you know how to ship that!

Team do-not-know-do-not-care

Some teams don’t care at all about accessibility. Then one person gets “bitten by the bug” and they want to make everything accessible but they’re not sure how, and they’ll spend a lot of energy and time trying to both learn how to make things accessible and also get their team members on board. Sometimes this leads to a new a11y advocate, but sometimes this leads to absolute burnout. Wait why am I saying sometimes. Inevitably, if you are trying to be the sole a11y person on your team, you will burn out. Period.

If this is you, and you don’t want to burnout (or maybe just can’t afford to!), don’t dismay. Start small. Get one other person on board. Document where improvements can be made. Ask questions. Look into automation that can help you fix the easier accessibility issues in your codebase. Accessibility is a journey and it’s about progress, not perfection.

Team legally required

Then you’ll have the kind of team where it’s required. This will be at maybe a University or a Financial Institution. Everyone accepts that this must be done. This may lead to a pretty great team or a pretty terrible one. I’ve seen both, and frankly it depends on the willingness of everyone to own it and commit to doing it. If anyone waits for it to be explicitly outlined in a Jira ticket, then it probably will not be so great.

Anyway. Consultants are brought in. QA testers are deployed to find issues. There’s a lot of “ship it and we’ll fix it when they tell us what’s wrong” going on, because an analyst crunched the numbers and decided that remediation was less expensive than doing it correctly the first time…even though they are incorrect. The bugs never end in these scenarios, and I’ve observed that team turnover seems to be a little higher in these kinds of teams than you’d think.

Team lets do this thing!

Another kind of team is one where you’ve decided that it’s important and it will be integrated from the get-go, but your accessibility advocates are of different backgrounds. I think this one is the most workable if you have an emotionally-evolved team, where egolessness is practiced and pragmatic decision-making is key. Let’s look at the different backgrounds and how they can compliment each other.

I’ve observed that you end up being a different kind of accessibility SME depending on where you started. If you started as a JS engineer and then integrated accessibility into your existing JS-all-the-things approach, you’re more likely to try to make your existing approach be accessible (somehow). If you came from a more traditional background of HTML/CSS/JS/ARIA, then you tend to think about the best markup first, and then how to add in the functionality with JS. This can create a nice push-and-pull collaboration, because you’re both looking at different parts of the issue and can really end up coming up with an approach that is rather thorough in the end.

I think this can create either a lovely balance on a team, or the kind of contention that will cause one or the other to quit. I’ve seen both. It really depends on how much these two types of folks can work together and put the user first, instead of their ego first. We work in tech, so I usually see battles of the egos. But I’m just gonna say, it doesn’t need to be that way. I’m here to tell you that better is not only possible, but I have experienced it many times. In fact, I’m on that kind of team right now. So I will wish the same for you, because I know it is possible.

Approaches to Success

There is always the temptation to use WCAG to “win” but I don’t think that results in the best outcomes for the team. There are times when I have to back off when one of my fellow engineers is pushing too hard for a specific solution. My experience has taught me that everything comes around again, and maybe in that second conversation, they’ll be more open to an improved accessibility approach.

There are also times when I have to be willing to repeatedly provide the feedback that the proposed solution is not WCAG-compliant, but I will try to avoid using words like “better” or “best practice” because that always feels like a personal attack. I know this because I have been on the receiving end of those kinds of things and despite my brain saying “it’s not personal,” what I’m really hearing is, “you’re not good enough.” I think that we all have to learn to set those feels aside and be able to hear those things but meh. Most of us aren’t there yet and as I get older, I have come to be okay with that.

I confess that my heart breaks every time I have to say “It’s not technically a WCAG violation, but it is a poor user experience.” Sometimes, the pragmatic thing is to let that go, and focus on what change can be made. Many times, I’ve observed that troublesome feature come back around because it ended up not working out for different reasons. Then you get another chance to improve it and provide a more complete accessible solution. That’s always rather satisfying.

So what approach works? In my experience, here’s what has worked for me, more times than any other approach I’ve tried:

  1. Be open to being factually inaccurate or not having a complete picture. Let new knowledge update your existing understanding. If someone proposes a new feature that is raising red flags but I can’t articulate why, I’ll set up some time to pair with them and see what they expect the user experience to be like. This usually clarifies things a lot more for me, and I can more clearly identify what I think the potential risks are.
  2. Ask more questions. Instead of saying, “this wouldn’t work because…”, I’ll ask “how would this work for keyboard-only users?” or other questions where maybe I expect the solution would not work. But asking the question provides the designer or engineer time to think about that themselves, and instead of giving a quick answer, I can support their learning journey by asking more questions. Sometimes, I’ll even be surprised and find that they’ve thought of my question and can answer it! So this has been the best tool in my toolbox, so to speak.
  3. Look for places where improvements can be made in a fast-follow PR. If I’m reviewing code and I find something that is an issue but not necessarily a blocker, I will immediately file a Jira ticket about it, and put that ticket link in my code review comment. That way, the author can see that I am not blocking their pull request but I am also indicating that it needs to be done (and usually sooner rather than later). I think there’s always a sense of relief when the person reviewing your code gives you a way forward, not just some theoretical reason (that usually ends up being a personal preference, ahem) why your PR is wrong.
  4. If it’s not WCAG conformant than it just can’t be okay to ship it. That has to be an agreed-on thing. The default version of the feature must be the accessible one. This has been hard for me in the past because I would just rather say, “this doesn’t work because it violates this WCAG Success Criterion, here are some other options that are conformant that you can try.”
  5. Finally, being approachable, encouraging, and generous is always helpful. I’ve built a reputation for being willing to deliver pragmatic solutions. It’s not just about being perfectly aligned with the spec, or perfectly meeting all of the WCAG Success Criteria. It’s about making progress in accessible experiences for our users, increasing our reach through knowledge-sharing, and investing my my colleagues in the ways that helps them see that I’m genuinely here for all of us to succeed.

I’m sure there’s more I’m forgetting but I’ll just sign off for now. I hope my own observations help you along your own journey.

Until next time. -M