Practical Developer Tips for Digital Accessibility Advocacy

Hat tip to all the other digital accessibility focused folks out there, fighting the good fight to advocate, educate, and drive accessibility forward.

This post is my little contribution to the rallying cry of doing everything we can to push digital accessibility and equal access forward. This is coming from my perspective as a web developer so these tips are going to skew pretty heavily in that direction, but I’m hopeful they give you ideas for your own unique situation.

Sometimes, all we need is to give ourselves permission to just do it anyway.

It’s hard out there#anchor

The difficulty of accessibility focused work is well known, and others far smarter than me have written some thoughtful articles about it.

Stress and adversity are standard for people who have chosen accessibility careers.

Sheri Byrne-Haber, CPACC

And because we care so much, we end up sinking a lot of our energies into this work. Mental as well as physical energy.

Nic Steenhout

From combating misconceptions and willful ignorance, to painfully slow progress and performative allyship with little action – there’s a lot to be stressed about.

But we have to keep trying#anchor

One strong common thread in an industry full of “it depends” grey areas is our dedication to equal access, it’s a primary motivator keeping us going.

Perhaps the most difficult thing is internalizing all of this. Digital accessibility work is not easy, but it is vital.

Eric W. Bailey

In the end, we must guarantee an accessible web that everyone can use and adjust to their needs. This is the basic promise of the web, a promise that is broken every day.

Eric Eggert

Practical Tips#anchor

As a web dev consultant, I’ve had the opportunity to be part of quite a few different kinds of teams and have worked on just as many different tech stacks. With that breadth of experience, I’ve also had the opportunity to try several ideas to push accessibility forward.

Here’s the top three that have worked for me, both in terms of delivering a more accessible end product and in sparking more interest and support from those around me.

Be the squeaky wheel#anchor

Sometimes you just know that accessibility is not a shared priority. Likely you’ve already had “the talk” with the team/stakeholders/client and, while they sounded receptive and interested, there hasn’t been much follow through.

In these situations, the best advice I have is to be the relentless “squeaky wheel“. For example:

• Ask about user stories, acceptance criteria, and testing instructions that can help ensure an equal experience is considered throughout their lifecycle.
• Ask about user testing, especially for complex and/or novel interactions.
• Ask accessibility related questions when talking through a new design.
• Bring up issues while in development, and in code reviews.
• Get a commitment to addressing tech debt on a regular cadence, and push for accessibility to be part of that.
• Make sure testing is happening on assistive devices too.

Some specific questions I recall asking recently:

• “What should focus states of interactive controls look like?”
• “How should this custom widget work for keyboard only navigation?”
• “Can we get annotations for the preferred tab order?”
• “How can we guarantee a minimum contrast for this text on a background image?”
• “The video player doesn’t have play/pause controls, can we add?”

The main goal here is to center accessibility in as many discussions as possible. Get others thinking about it and asking questions too. Show the practical benefits, explain how minor course corrections early on can save a lot of time later.

Celebrate attempts as well as wins#anchor

There are few topics in our industry with more grey area and “it depends” answers, so it’s natural for folks still new to accessibility to be hesitant or misinformed.

In fact, I’ve put in several years of reading, learning, and applying accessibility best practices and eventually built up enough experience and confidence to even go get CPACC certified. And yet, I still struggle with imposter syndrome.

There are so many “moving parts” to accessibility that it’s hard to define specific technical requirements.

Nic Steenhout

The key is to identify an enthusiasm to learn and improve in those around you, and encourage that in any way you can. For example:

• Give kudos when you notice all color combinations in the design system are accessible, then show how to annotate appropriate active, focus, and hover states for interactive controls.
• Celebrate their effort put into adding ARIA roles to a new interactive widget, even if they’re all wrong. Then coach them through how to fix it, and explaining the first rule of ARIA.
• Give appreciation to the QA folks that try a screen reader for the first time, and explain the difference between tabbing through operable controls and using a screen reader to navigate all content.

The main goal here is to encourage more growth and learning, and to build up enough psychological safety for folks to feel comfortable asking questions and trying. Be their mentor and provide the guardrails, help them work through it on their own and in real situations.

When all else fails, do it anyway#anchor

This may be the most controversial, but I can’t deny it’s effectiveness when applied at the right time. When you come across situations where you know the chosen direction is going to be inaccessible, and you have the means (and the spoons) to make it accessible anyway, just do it anyway.

Examples from a developer’s perspective:

• In the video player missing pause controls scenario noted above, go ahead and add them in during development. Force someone to say “yes I acknowledge this is bad for accessibility and still want you to remove it” and see how often that happens. In our remote first world, this usually means you also have it in writing.
• If you see a non-decorative image without alt text – and no path to get it “officially” provided – do your best and add it yourself.
• Links that should be buttons, buttons that should be links, interactive controls using span and div tags. If you’re touching that code anyway, fix them.
• No design direction on focus and hover states and no connection to the design team? Yeah I hate that too, but add them anyway and try to follow the designs as best as you can. If someone hates it, you’ll hear about it and will get a chance to make it even better.

The main goal here is to do our best to release products that are just a bit more accessible then they otherwise would have been. It may not move the needle very much for accessibility as a whole, but will help the people using your digital product have a better time.

There’s a reason this one is last, because it’s generally not a great idea to be subversive, and depending on your situation could even land you in a bit of trouble. So please do take some caution.

From my experience, there have been countless situations where I’ve made the decision to do it anyway and no one noticed, because they’re not looking for it. There are also many situations where my work was quite noticeable (like the pause controls on a video) and someone asked about it. More than half the time they’ll say something like “huh, okay then” and move on, sometimes those people slowly turn into accessibility advocates too.

Every bit helps#anchor

I leave it up to you to determine which may be appropriate for your situation. Remember that the overall intent is to drive progress despite an initial lack of support, while you continue to try building that support.

Sometimes, these tips help spread the word and builds momentum. Sometimes they don’t. Either way, every bit helps when it comes to accessibility.