If I want to talk to a developer about accessibility in terms they'll understand and relate to, I sometimes fall back to the idea that accessibility is technical debt.
The thing about technical debt is that we all have it. All products have accrued over time some technical debt. A little bit of technical debt is okay. Maybe it's even needed to push people to do better or to force them to come back pay down the debt and find some refactoring opportunities that will improve the overall product.
Why is a little technical debt okay?
Think of:
- Time to market
- Learning and iteration
- Competing priorities
- Future uncertainty
The thing about accessibility as technical debt is that it's not a little bit of it. I usually see a lot of technical debt. And it's ever-growing, like a cancer cell. Many don't realize they've accrued this debt until their customers make them aware of serious accessibility blockers in their products. Or worse - the threat of a lawsuit.
Why is accessibility usually a lot of technical debt?
Because you just didn't realise you had it until you heard about accessibility. And by then it's piled up at your front door.
That's why I highlight how important it is to start incorporating accessibility into your current work cycle.
Yes, it will take time. Do this gradually.
Yes, it will cost money. But not as much as you stand to lose by not paying down the debt.
Yes, you will create more technical debt along the way. But like I said, a little bit is okay.
The one thing I don't advise is to push and fix everything at once. It's not doable.
Instead, set aside a specific amount of time in each sprint to focus on accessibility. You can make steady progress without blocking any ongoing work. You won't overwhelm your team and you can still focus on your business priorities.