Yesterday, I wrote how ignoring accessibility means building on a shaky foundation. I feel like that deserves a bit more attention.
How come every feature you ship on an inaccessible base makes the problem worse?
Let's imagine a product feature with a modal that asks for some confirmation from the user.
You didn't bother with keyboard accessibility. So it has some issues. It doesn't trap focus inside of it, it can't be dismissed with a keyboard and it won't return focus to where they were before the modal opened.
But it looks great, it's fancy and modern.
In fact, you like it so much, you decide to add it to all new features going forward. You also create some tickets to back-port it to existing features.
Here's what happens next.
A year from now, someone finally prioritises accessibility. Your developers start digging in and realise the modal is fundamentally broken. Now they have to spend time to dig around everywhere this modal is used and figure out all the use cases, create tickets for all instances, write test cases against them and duplicate fixes.
It turns out that all this time, you weren't just maintaining bad code. You were actively building more bad code on top of it. Each new modal compounded the last problem.
What could have been fixed with a few hours of work in the first sprint now requires weeks of untangling dependencies. New features get delayed. Your engineers get frustrated. Product owners start asking why this is taking so long.
You avoided a simple refactor and now you have to rebuild most of it anyway.
Accessibility debt is just like other technical debt.
The longer you wait, the more expensive it gets, until eventually the only solution is starting over.