The Cost of Accessibility Tech Debt

Now I get why the Project Managers never took accessibility issues seriously!

previously on A11y News:

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

Well, well, well, how the tables have turned. After comparing speed running to project management, and a heated discussion in my LinkedIn comments, I learned that the often quoted “29 times” derives from the Boehm’s Curve in agile software development. It applies to all software defects, not accessibility issues specifically.

Now I get why the PMs never took us seriously!

A moment of shame for me because I didn’t check my sources… Okay, over because we’ve got maths to do:

Boehm’s Curve Formula

Boehm’s Curve can be approximated with this formula:

\(C(t) = C_0 \cdot e^{kt} \)

• C(t) is the cost of change at time t

• t represents time or phase in the development process:

  • 0 = requirements

  • 1 = design

  • 2 = implementation

  • 3 = testing

  • 4 = maintenance on production

• C0​ is the base cost of fixing a defect (e.g., if found during the requirements phase)

• k is a constant that determines how rapidly the cost grows

Since we want to stick with Boehm’s Curve to make a sensible comparison, we need to get that constant k. To find it, we can use known cost multipliers from Boehm's example data:

The maximum on the graph is 100 at Maintenance, so t=4 gives us:

\(100\cdot C_0 = C_0 \cdot e^{kt}\)

Dividing both sides by C0 and counterspelling e with its natural enemy, the natural logarithm, leaves us with:

\( \ln(100) = 4k \)

\(k = \frac{\ln(100)}{4} \approx \frac{4.605}{4} \approx 1.151 \)

Solve this for k and boom: We have a value. 1.151

So the Cost of Amending Triples with Every Phase

Laura, what? You just said it’s 1.151? Indeed, but in the magical world of mathematics, that cute e in our equation isn’t another variable. e represents Euler’s number, the base of the natural logarithm and exponential function, and is approximately equal to 2.71828.

The Unknown Factor: Nobody Does It Wrong on Purpose

The assumption is that software developers don’t build it wrong on purpose the first time. Hence, we need to factor in the time to research what the issue is and how to fix it.

For example, coding a button as

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

Takes maybe a minute, is easy to understand for any developer joining later, and comes with all button functionalities built in (because, well, it’s a button).

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>  

Would you expect any junior to see through what is happening here at a glance? It’s convoluted, we have tabindex and alert in there, but do you, as a not-necessarily technical PM, know why they are here?

Cost of the Knowledge Gap

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.

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 dev 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?

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.