{"id":1798,"date":"2026-09-04T10:16:00","date_gmt":"2026-09-04T17:16:00","guid":{"rendered":"https:\/\/galm.sg-host.com\/?p=1798"},"modified":"2026-09-09T06:43:01","modified_gmt":"2026-09-09T13:43:01","slug":"how-fixing-an-accessibility-bug-can-cost-15000","status":"publish","type":"post","link":"https:\/\/www.evinced.com\/blog\/how-fixing-an-accessibility-bug-can-cost-15000\/","title":{"rendered":"How fixing an accessibility bug can cost $15,000"},"content":{"rendered":"\n

What does it cost your organization to let an accessibility bug slip through to production? <\/p>\n\n\n\n

If you never intend to fix the bug, that cost is low. But if you do, the cost can be substantial.<\/p>\n\n\n\n

How do we know? Because we asked. We sat with customers who care deeply about accessibility, and several of them were candid about exactly what they were spending to fix bugs found in production, sharing their numbers with us under NDA. We also asked our own team the same question about our own development process. <\/p>\n\n\n\n

The answers varied, of course. But what was consistent was how easily and commonly a bug found in production can cost at least $15,000 to fix. (You may remember this number from our post on false negatives<\/a>.)<\/p>\n\n\n\n

And while $15,000 might sound extreme, rest assured it all adds up once you trace where the costs actually come from. Let’s break it down.<\/p>\n\n\n\n

The scenario<\/strong><\/h2>\n\n\n\n

To be clear: one developer fixing a line of code in real time won’t come close to $15,000. But a bug found in a live production site \u2013 by an end user or an auditor, months after the build shipped \u2013 is a very different story. <\/p>\n\n\n\n

By that point, fixing it isn’t work for one person. It requires many team members, many steps, and a lot of coordination overhead.<\/p>\n\n\n\n

As a first step in going through this, here\u2019s a summary of the resources costs generated at each phase of remediation.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Exhibit 1. Resource Cost Summary, Remediation of Production Accessibility Bug<\/strong><\/p>\n\n\n\n

Phase<\/th>Tasks<\/th>Resource Cost<\/th><\/tr><\/thead>
Triage<\/a><\/td>Read list, reproduce issues, prioritization meeting with team, etc.<\/td>$3,775<\/td><\/tr>
Diagnosis<\/a><\/td>Root cause analysis, decide fix approach and teams involved, etc.<\/td>$3,950<\/td><\/tr>
Fix<\/a><\/td>Create new design, check accessibility of design, engineer the design, perform self-tests, etc.<\/td>$4,630<\/td><\/tr>
Review<\/a><\/td>Perform functional tests, automated accessibility scans, assistive tech checks, look at adjacent components, etc.<\/td>$2,250<\/td><\/tr>
Deployment<\/a><\/td>Merge to production, monitor, close JIRA ticket, update release note, communicate to fix to stakeholders, etc.<\/td>$600<\/td><\/tr><\/tbody>
Total<\/strong><\/td><\/td>$15,205<\/strong><\/td><\/tr><\/tfoot><\/table><\/figure>\n\n\n\n

Discussion<\/strong><\/h2>\n\n\n\n

When we say \u201cresource cost,\u201d what we mean is we are tallying employee time spent and weighting it by the fully loaded hourly rate1<\/a><\/sup> for each employee\u2019s time. <\/p>\n\n\n\n

So another way of asking, \u201cWhy so expensive?\u201d is to ask \u201cWhy does it take so much time?\u201d<\/p>\n\n\n\n

There are several reasons.<\/p>\n\n\n\n

Hours multiply by headcount<\/strong><\/h3>\n\n\n\n

A one-hour meeting with an accessibility manager, engineer, designer, and product manager is actually four hours of billed time. That’s before anyone has written a line of code or opened a design file. The more people required to align on a fix, the faster the hours compound. This is the single biggest driver of why complicated bugs get expensive: it’s not any one person’s time, it’s the coordination overhead across all parties involved.<\/p>\n\n\n\n

Context switching costs time<\/strong><\/h3>\n\n\n\n

By the time an audit report or the complaint from an end-user arrives, the team has moved on. The original engineer may be on a different project. The designer who built the component has long forgotten it and is working on something else. Re-entry into old work takes time. Team members must reopen branches, reinstall dependencies, re-learn interaction logic that made sense six months ago and is now forgotten. Even professionals need time to context switch so they can get the fix right.<\/p>\n\n\n\n

Complex component problems have a blast radius<\/strong><\/h3>\n\n\n\n

A multi-select dropdown component likely isn\u2019t just one instance on one singular page. It\u2019s very likely that the component lives on multiple pages, such as the Search page, the Filter panel, the Settings form, and the Checkout flow. Every fix has to be validated everywhere the component appears. That multiplies QA scope dramatically.<\/p>\n\n\n\n

(Manual) accessibility review is complicated<\/strong><\/h3>\n\n\n\n

There’s a difference between a fix that looks right and a fix that works across operating systems, browsers, and assistive technologies. Teams have to check if the solution works in NVDA on Firefox, VoiceOver on Safari, and keyboard-only navigation across all those pages. And if something breaks in one instance, it\u2019s back to the drawing board or, at least, back to the conference room for a prioritization debate.<\/p>\n\n\n\n

The people in the room are expensive<\/strong><\/h3>\n\n\n\n

Accessibility isn’t a solo job. The accessibility manager, product manager, designer, engineer, QA, and sometimes an external subject matter expert (SME) and consultant are all in this process at different points. Each of their hours costs money, and each handoff adds coordination overhead. <\/p>\n\n\n\n

It\u2019s important to note that the bug in the scenario above assumes availability of accessibility expertise. The cost for organizations without access to in-house (or out of house) accessibility expertise would be even higher.<\/p>\n\n\n\n

First-hand experience at Evinced<\/strong><\/h2>\n\n\n\n

Still skeptical? We understand. So, in the interest of transparency, here’s a story from our own backyard.<\/p>\n\n\n\n

Not long ago, the Evinced team discovered a multi-select dropdown component with a serious accessibility problem, in production, after the fact. It was complex. It required five weeks of work from a team of four to five people, including our own accessibility specialists, who are very good at what they do. <\/p>\n\n\n\n

If you run the math on that, the cost to our team was well over $100,000. So when we say $15,000 is a reasonable number, we mean it.<\/p>\n\n\n\n

Consider the scale<\/strong><\/h2>\n\n\n\n

Now consider the scale of the problem beyond a single bug. <\/p>\n\n\n\n

When new customers come to us for the first time, it is very common for their website to have 10,000 or more critical accessibility issues. Evinced reduces that workload significantly by clustering issues by coding pattern into what we call components. Even so, it’s common for customers to arrive with hundreds of component-level problems. At $15,000 each for 200 components, that could be $3 million of resource cost.<\/p>\n\n\n\n

And, sure, not all bugs cost $15,000 \u2013 maybe some are $5,000, some are $10,000, and some are $20,000+ to fix. It\u2019s still money that\u2019s already been paid to build those features once. Now the organization has to pay to build them again, accessibly. <\/p>\n\n\n\n

To put it frankly, if you pay to do it wrong, you\u2019ll have to pay to do it right. <\/p>\n\n\n\n

None of the costs above are the result of negligence or bad engineering. They are the predictable consequence of finding accessibility issues late. You pay a premium to find and fix bugs after context has faded, teams have moved on, and components have spread across your product.<\/p>\n\n\n\n

As your organization considers accessibility tooling, it\u2019s natural to ask whether your accessibility budget can afford it. But can you afford not to? <\/p>\n\n\n\n

See for yourself<\/h2>\n\n\n\n

Your company’s numbers may well be different from our estimates. To calculate it precisely, download this Excel model<\/a>. Plug in your team’s rates and anticipated hours to get an idea of what an accessibility bug found in production could cost your company.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n\n\n\n

Detailed breakdown of each phase<\/h2>\n\n\n\n

Triage Phase<\/h3>\n\n\n\n
Step<\/th>F<\/th>H<\/th>P<\/th>RCR<\/th>Total<\/th><\/tr><\/thead>
Read and triage the audit list to select the item to fix, mapping issues to WCAG criterion or severity level (critical\/serious\/etc.).<\/td>A + PM<\/td>4<\/td>2<\/td>$150<\/td>$1,200<\/td><\/tr>
Reproduce the targeted issue.<\/td>Dev\/QA<\/td>2<\/td>1<\/td>$200<\/td>$400<\/td><\/tr>
Decided with larger team whether to fix the issue.<\/td>J<\/td>2<\/td>4<\/td>$150<\/td>$1,200<\/td><\/tr>
Decide which sprint to fix the issue in.<\/td>J<\/td>0.5<\/td>3<\/td>$150<\/td>$225<\/td><\/tr>
Write JIRA ticket for bug to be fixed, with an owner assigned, translating WCAG criteria to practical terms if necessary.<\/td>PM\/A\/QA<\/td>2<\/td>2<\/td>$150<\/td>$600<\/td><\/tr>
Park deferred items somewhere, documented, so the team can return to them.<\/td>PM<\/td>1<\/td>1<\/td>$150<\/td>$150<\/td><\/tr><\/tbody>
Total<\/strong><\/td><\/td><\/td><\/td><\/td>$3,775<\/strong><\/td><\/tr><\/tfoot><\/table><\/figure>\n\n\n\n

Key: <\/p>\n\n\n\n