When we talk about accessibility, we often frame decisions as good or bad. Product is rarely like that, in black and white. What was it!? Only a Sith deals in absolutes? Yes, I like Star Wars.
In reality, many choices only look good or bad when you look at them on the timeframe you're measuring.
For example, skipping accessibility testing might help you hit that deadline. When you don't have to think about which semantic element works here and instead throw ARIA at a div, you might feel you're moving faster. You could leave keyboard support until v2 so you can keep the momentum going.
And in the short term, these decisions are sensible. Efficient even.
The problem is that you're building up technical debt. And time has a habit of collecting interest on that debt.
What saves a day this month can cost weeks next quarter. Accessibility issues become harder to untangle once patterns are all across your product. You start spending more time fixing and reworking than you'd have spent doing things properly in the first place.
But I understand why.
You're looking at accessibility as a cost because the benefits are spread across a longer timeline. Better usability, fewer issues, reduced maintenance costs and a wider audience don't all arrive all at once.
I think the difference between a good decision and a bad one isn't the decision itself, but rather how far into the future you're willing to look.