The time objection usually lands before anything else.
It lands before I've proposed anything specific. Before I've talked about any numbers or outlined any scope. They don't know yet what the work actually involves and someone already says "we're just too stretched right now" and that's that.
I used to fight this head on. I'd make the case for why accessibility matters, why it couldn't wait, why the cost of doing nothing was higher than the cost of doing it right then. It never really worked.
I was answering the wrong question.
The time objection isn't about time. Not really anyway. They're just scared about the unknown. Nobody told them whether this accessibility thing would take a day, a week or six months. They assume the worst. And then they do what any rational person does when they're asked to commit an unknown amount of their most finite resource. They say no.
And they're right in doing that. Time really is a finite resource. You can't get it back once you've spent it. That makes people really careful with what they spend it on.
So I was wrong to lead with importance and the moral or legal argument. All these were valid arguments and necessary at some point. I'd need to talk about them, sure. But they're not a good conversation starter.
Because none of them answer what's really sitting in the back of their minds. How much of my time is this going to take?
Until I answer that, the objection stays on the table.
Before I can make the case for why accessibility matters, I need to give people a rough picture of what starting actually looks like. They don't care about the full roadmap, just what the first step is and roughly how long that will take.
Looking back, this conversation isn't the same for everyone.
A new product and an established one are two completely different situations.
If you're building something new, the time investment is relatively low. You're not fixing anything. This is the ideal scenario because you have the chance to build it right from the start. The overhead is small and it gets smaller the longer you keep at it. The time investment is relatively low.
But an established product is a different story. That codebase has history. It's been touched by 20 different developers. They made tons of decisions they already forgot because I doubt anybody documented any of it.
That's where the time objection carries the most weight. And honestly, I get it.
So for an established product, an audit seems like the obvious starting point. Go in, find out what I'm dealing with, then decide what to do about it. And in theory, that seems right. It could turn an unknown into a known and that gets me closer to answering their time objection.
The problem is what happens when the audit comes back.
A full audit on a large product can surface hundreds of issues. That sucks because instead of making accessibility easier to say yes to, I've managed to hand someone a document that makes it feel like no is the only answer.
That audit becomes the thing that kills the conversation.
But the fix isn't to skip the audit. I'd be back to not knowing what I'm dealing with. I'd rather scope it properly. Pick the pages that matter most and start there. Get some findings I can act on rather than a list so long it dies in a backlog.
Most people, when they find out they can make a meaningful start in a few days, they can and do find a few days in their busy schedules. The work is rarely what makes them say no. The not knowing what they're saying yes to is.
So my goal is to replace the unknown with something that has some substance and some edges. The time objection mostly takes care of itself by that point.
And that's because it was never really about time, but uncertainty.
The money objection works the same way, except what's hiding behind it isn't uncertainty, but ROI.
We'll get into that tomorrow.