I got this question earlier this month. I'm paraphrasing a little bit for clarity, but it goes a bit like this:

We think it'd be better to start working with accessibility a bit early in the process next time. Wouldn't that save some work later on? How early is early enough?

First off, yeah, it warms my heart when I hear stuff like this coming completely unprompted.

So how early is early enough to start thinking about accessibility in the software development lifecyecle (SDLC)?

Follow the money backwards!

Retrofitting accessibility costs more. Not a little more, but a lot more. How much more depends on quite a few things, but definitely one of them is how much work the team already did before they realised they hadn't considered accessibility. And shifting these efforts earlier in the SDLC dramatically reduces the costs.

Let's work through an example. Say we're looking at a modal dialog that's inaccessible:

• it can't be dismissed by keyboard and clicking outside does nothing
• it has no close button
• it doesn't render the content underneath it inert, so you can still Tab around the rest of the page
• it's not announced in any way to a screen reader that it's open or that it will open
• has colour contrast issues due to some fancy light grey text

Say, we caught it after the product launched. It has to work its way back all the way to the beginning and sit in a list with a designer to fix the contrast issues. Then it goes to dev to take care of the interactions, off to QA to test it and devops deploys the fix. Marketing can then pat themselves on the back about this huge improvement.

If each of these steps requires:

• 1 hour of planning and debate to prioritise,
• 1 day for the person responsible to pick it up and do it,
• and figure half a day in between when the product owner keeps asking about the status of it,
• not to mention that these are not consecutive days, then...

We're looking at about eight working days, or two calendar weeks, give or take. And that's if everything goes smoothly. Don't forget code review, code merging conflicts, design critique.

That would still be great. The problem is most teams work off a set release schedule. So they only release updates every two months. Or three. Or six.

All during this time, that modal cannot be used by someone with a screen reader or keyboard. There's no way to quantify that though. You can't count what you can't see.

But I digress. Back to those eight days. At a measly 300€ per day (figuring between 30 and 40€ per hour), that comes to about 2400€. For a broken modal. Yeah, yeah. Sure, the math is not exact and they're not literally spending eight hours per day every day on this. But if they did it from the start, it would have added probably 4-5 hours to the process. So about 200€.

To be honest, I've heard the number 10 times as expensive to fix post-release rather than in the design phase. I don't have a actual study handy, so my numbers are just as good for our use case, if you consider 2400 divided by 200 is 12. So 10-ish.

Going back to the original team and their question, for them, the accessibility "work" held up product release by about a week. This was a small product developed by a small team with enough know-how and good will to go back and re-do some things.

However, the figures scale with project and team size. So your mileage may vary.

How early is early enough?

As early as you can stomach it, but not later than whenever the cost of doing it tomorrow exceed the cost of having it done today.