The typical answer

Whether you call it an accessibility audit, WCAG audit, or website accessibility evaluation, the big question usually comes after the report is delivered: how long will remediation take to remediate accessibility audit findings? I’ve been working in digital accessibility for over a decade, and this is probably one of the most common questions I’ve been asked when discussing audits with folks. The “canned” answer is, it depends because, well, it depends.

We need a better answer

The problem with the “it depends” answer is that people need to understand how long it takes to remediate accessibility audit findings to plan the effort. Often there is a driver like the ADA Title II or 504 HSS rules deadlines that require specific timing. Most settlements to ADA Title III cases have deadlines, and sometimes it’s just a matter of figuring out how the work is going to fit into competing priorities.  The good news is that through my years I’ve come up with a better answer. Not a perfect answer but a better answer.

An accessibility audit is a structured review of a website, application, or digital product against accessibility standards such as WCAG. The audit identifies barriers that affect people with disabilities and gives teams a prioritized set of findings to remediate.

A useful starting estimate for the time to remediate the finding is 2 to 6 hours per accessibility issue, with the total timeline depending on scope, issue complexity, developer experience, and how much remediation time the team can reserve each week. For planning, I recommend creating a low, likely, and high estimate rather than relying on a single number.

The Accessibility Remediation Estimator

Before we go deep into calculations, we have an Accessibility Remediation Estimator that will do all the hard work for you.  The estimator is nice because it makes it easy to play with the numbers, calculate ranges, and estimate allocation.

The estimator is designed to use pre-audit data. There is also an Advanced Accessibility Remediation Estimator that narrows the estimate based on the results of a completed accessibility audit.

If you’re a geek like me, you want to know the variables and math behind this better answer. Let’s start by digging into all the factors that can affect remediation time.

The factors that affect remediation time

The better answer is in no way “canned” as it takes some thought and calculation. With a little effort, you can get good estimates that allow you to plan.  Let’s look at the variables that lead to the “it depends” statement you hear from most people. They’re the basis for understanding how to estimate. Here are the major factors that drive remediation time:

• The scope of the accessibility audit
• The complexity of the audit target (the website or application)
• The number of issues found in the audit’s scope
• The complexity of the issues to remediate.
• The ratios of complex to noncomplex issues
• The skill level of the developers assigned to the issues
• The priority assigned to the effort and the time allocated to fixing the issues
• The size of the team assigned to fix the issues.

With all those factors, it’s pretty easy to understand why most folks shake the question off with the “it depends” response. But if we work with some averages and boil these factors down to a few basic figures, we can get a pretty darn good estimate, which is all most people are really looking for. What does the formula look like and what are the assumptions we need to work with?

The calculation

Scope

The first thing to pin down is scope. For our purposes here, we’ll think of that in number of pages or screens. (We’ll use screen universally from here out.) You’ll find a few different approaches out there, including using components and other variations. I think the most common way to express scope and the one that fits most closely with the WCAG-EM is screens, so we’ll go with that. How many screens are in the evaluation?

Number of Issues

Here is the start of our formula:

Number of screens × estimated issues per screen = total estimated issues

Time to fix

The next question is: how long does it take to fix an issue?  Given all the same conditions as above, I like to use an average of 3 to 4 hours per issue. You can adjust that up and down based on the complexity of the target and the accessibility skill level of the developers doing the work.

Now our formula looks like this:

(number of screens*number of issues per screen)*average time to remediate an issue = total number of hours needed to remediate.

Resource allocation

Well, look at that. We now have an estimate of how much time it will take. Now we just need to factor in the resource allocation. How many developers will be assigned to the remediation, and how many hours per day will they allocate to remediating the issue?

Now our basic formula is complete:

((number of screens*number of issues per screen)*average time to remediate an issue)/(number of developers*number of hours per day) = total number of running hours to remediate.

Here is an example:

20 screens * 12 issue per screen = 240 issues

3 hours per issue to remediate (3 hours * 240 issues = 720 hours)

2 developers working 6 hours per day = 12 hours per day (720 hours / 12 hours per day = 60 working days or12 weeks or 3 months.)

Creating a range

Now that you know how to get to this better answer, let’s look at some good ways to use it for planning and to inform your team. Given the amount of guess work were doing here, I like to work in ranges. Calculate what I guess to be a bit low and a bit high and have the final answer. This range is what I share with the stakeholders. Not only does it show a possible best- and worst-case scenario, it makes it clear that it’s an educated guess and not a promise.

Here is an example range based on our scenario above. We can start with something like 9 issues per screen and 2 hours to remediate on the low end and 15 issues per screen and 6 hours to remediate on the high end. That would give us a range of 30 to 150 days, with it likely to land at around 12 weeks. Not perfect, but something we can use to plan the effort and allocate resources. If you want a narrow range, tighten it up.

We can also reverse it and play with the number of resources and time allocated to each resource to estimate the allocation we’ll need to hit a certain time frame. This is where Inclusion Impact Accessibility’s Accessibility Remediation Estimator comes in handy. It’s much easier to plug in the numbers and get all the different numbers you need. Give it a try and see if you can provide your team with a better answer.