Winning the Accessibility Battle

How to Handle Resistant Developers Without Losing Your Sanity

Originally posted on Medium.com on March 18, 2025.

So, you’re a designer trying to push for accessibility, but your dev team fights you at every turn. Sound familiar? It’s like trying to convince a toddler that broccoli is good for them. Resistance is real, but guess what? You can win this battle without turning every conversation into a war.

If your developers are constantly questioning your every move when it comes to accessibility, this blog post is for you. Here’s how to get them on board, make accessibility non-negotiable, and keep your sanity in the process.

Step 1: Make Accessibility a Team Sport, Not a Dictatorship

First off, let’s get one thing straight: Developers aren’t the enemy. They’re just wired differently. They prioritize efficiency, performance, and minimizing scope creep. If you frame accessibility as extra work that only you care about, of course they’ll resist.

The Fix: Make accessibility a shared responsibility. Position it as a team goal rather than a designer mandate.

What to Say:

“Hey, I get that this feels like extra work, but accessibility is part of a great user experience. It helps everyone, not just users with disabilities. How can we make this easier to implement?”

Why It Works:

• You acknowledge their concern instead of dismissing it.
• You shift the conversation from “Do we have to?” to “How can we?”
• You put the ball in their court, making them part of the solution.

Step 2: Use Documentation as a Shield

If your devs love arguing, don’t argue back. Let the documentation fight for you. Instead of getting into a debate about whether an ARIA label is “really necessary,” point to official sources that make the case for you.

The Fix: Have trusted accessibility guidelines ready to share.

Resources to Drop in Slack Like a Boss:

• W3C ARIA Authoring Practices Guide
• WCAG 2.2 Official Guidelines
• WebAIM’s Guide to Accessible Forms

What to Say:

“This isn’t just my opinion — this follows WCAG and best practices. Here’s the reference if you want to check it out.”

Why It Works:

• You remove personal bias from the conversation.
• You reinforce that accessibility is an industry standard, not a preference.
• You make it harder for them to brush off your request.

Step 3: Turn Resistance Into Ownership

Developers don’t like being told what to do, but they do like solving problems. Instead of forcing accessibility on them, invite them to help figure out the best implementation.

The Fix: Ask for their input on accessibility solutions instead of dictating what they need to do.

What to Say:

“I get why this feels unnecessary, but we need to make sure screen reader users have full context. Do you think an ARIA label is the best way, or is there another approach we could try?”

Why It Works:

• It makes them feel like they have control over the solution.
• It removes the “us vs. them” tension.
• It creates collaboration instead of resistance.

Bonus Move:

If they push back hard, say:

“How about we test it with a screen reader and see if it actually helps users? If not, I’m open to adjusting.”

Now they have to prove you wrong with data, not opinions.

Step 4: Make QA an Ally, Not an Afterthought

Here’s an overlooked power move: Train your QA team to catch accessibility issues. If devs know QA will flag missing ARIA labels, proper focus states, or contrast failures, they’ll get ahead of it instead of waiting to be called out.

The Fix: Involve QA early & set accessibility expectations.

What to Say to QA:

“WAVE is a great start, but can you also test with a screen reader and keyboard navigation? If something seems unclear, let’s document it so devs can address it.”

Why It Works:

• Developers will take accessibility more seriously if QA is checking it.
• It ensures issues are flagged before release, not after.
• It makes accessibility part of the process, not a last-minute fix.

Step 5: Know When to Pick Your Battles

Not every accessibility request is worth going to war over. If it’s critical (like missing alt text, keyboard traps, or unreadable contrast), stand your ground. If it’s a minor tweak (like an ARIA label on a cancel button with clear context), consider compromising.

The Fix: Prioritize high-impact issues & document decisions.

What to Say:

“I get that this feels small, but accessibility issues often go unreported. Let’s fix it now rather than when it becomes a blocker later.”

Why It Works:

• It reinforces that accessibility saves time in the long run.
• It avoids unnecessary friction over low-impact issues.
• It helps you focus on what truly matters.

The Takeaway: How to Win the Accessibility Battle (Without Burning Bridges)

Instead of butting heads with resistant developers, try:

✅ Framing accessibility as a shared responsibility.

✅ Using documentation to support your case.

✅ Inviting devs to help solve accessibility challenges.

✅ Involving QA early to reinforce expectations.

✅ Picking battles wisely & documenting decisions.

Accessibility isn’t an option. It’s a requirement. The trick is getting developers to see it that way without turning every conversation into a fight. Use these tactics, and soon enough, you’ll turn resistance into advocacy.

What’s Your Experience?

Have you faced dev pushback on accessibility? How did you handle it? Drop your war stories (or success stories!) in the comments below!