The Cost of Accessibility Tech Debt

On average, amending accessibility bugs in the testing phase costs 30 times as much compared to allocating the resources to baking accessibility into the initial development stage.

Imagine this: Coding a button as

<button class="favorite styled" type="button">Add to favorites</button>

How long would that take? A minute? (If you’re thinking really hard about the copy.)

Let’s compare with the alternative:

<div role="button" tabindex="0" onclick​="alert('Button clicked!')" onkeydown​="if(event.key === 'Enter' || event.key === ' ') { alert('Button clicked!'); }">
 Click me 
</div> 

With all due respect: What is this? But let’s say this is the code you’re starting with.

Cleaning Up A11y Debt

1️⃣ First, you need to test it to find the issues: automated testing tools, screen reader software, keyboard navigation check, etc.

2️⃣ In half of the cases, this button didn’t work. Now, we have to document the what, how, why, and when of it. That’s a lot of bug reports.

3️⃣ Those items are in the backlog now. Cool, but unfortunately, we can’t just chuck them all at the development team at once. Time to allocate resources.

4️⃣ This is the tricky part: If your team didn’t know about accessibility before staging, how long will it take them to fix it now?

---

The button may be a dramatic example, but it illustrates the problem well: The cost of accessibility tech debt is not in the code but in the knowledge gap between finding the issue and fixing it.

It costs less time to look up ‘accessible components [insert your favorite framework here] stackoverflow’ than testing, finding, documenting, branching, and re-deploying the changes.