How do I handle push-back from developers who say accessibility fixes will slow them down?
This is a classic one. I wish I could say it's as easy as telling developers that accessibility isn't extra work bolted on at the end and that it's part of building good software from the start.
But it's not as easy as that.
What I've found works in more cases than not, is to answer their real concern.
Developers don't like being told they have to do more work on the same deadline.
First off, acknowledge this otherwise real concern. And then flip the script. Show how accessibility issues found later cost way more to fix than getting them right upfront.
The problem is you've dropped accessibility in their lap after they've already coded things. So next time, bring it up in sprint planning. And get them involved early.
Believe it or not, developers actually care about user experiences and the last thing they want is to push shitty stuff out. But, but! They have this thing against perfection. They'd rather have something working fast and see it live. It's a thing of pride: "I've done that." So show them accessibility isn't about perfection. You're all just trying to avoid shitty user experiences.
So aim for some quick wins. Go through things like proper heading structure and alt text. These aren't massive time sinks and they make a huge difference. Once they see how straightforward some fixes are, I've noticed resistance usually drop.
And honestly? I like to frame it around code quality. Most developers care about writing good code. Accessible code is often cleaner, more semantic and easier to maintain.
I've never had to do it so far, but if push-back continues, I'd escalate it. Accessibility isn't optional and management needs to back that up with realistic timelines and priorities.