Just announced: Level Access and eSSENTIAL Accessibility agree to merge! Read more.
Magnifying glass evaluating the accessibility of a website

One question we receive a lot at Level Access is, how long does it take to bring a system into compliance with Section 508 or WCAG. This post is an attempt to shine some light on that question – thoughts and comments are welcome.

The time to remediate a site or application varies widely between sites and there is no generic time to use in a model that applies across all sites or applications. The time to remediate any a given system is based on three key factors:

  1. the number of operable pages or screens in the system,
  2. the overall user interface complexity of the site or application, and
  3. the frequency and types of violations found in an assessment of the system.

Items one and two can be determined through a basic inspection of the code base and user interface of a system. Item three requires an audit of the system.

The key factors can be used to determine a rough model of the time needed to remediate a system and make it accessible. The actual time to complete the fixes then is impacted by the training and expertise of the team as well as the testing support they have. For the average application Level Access looks at, if the team is proficient in accessibility, has working experience in making applications compliant, and is backed by a good testing team they can remediate the average page or screen in around eight hours. Adding in testing time and accounting for a regression cycle of fixes, Level Access’s common model targets twelve hours per page as a remediation estimate. In fact, that is the time model Level Access uses as a basis when quoting out remediation work for sites and applications for customers. The time estimate assumes a team with expert level accessibility development knowledge coupled with a QA team with expert level accessibility testing knowledge.

To get internal teams up and running the provisioning costs are comprised of direct training and infrastructure costs, training time and experience. Direct training and infrastructure costs are the costs for accessibility training and an accessibility infrastructure like AMP. Training time and experience required vary based on role. For QA, expert-level accessibility testing generally requires about 480 hours of training and monitored work to provision a person. For many clients, these costs make pulling auditing in-house a poor ROI in terms of both budget and calendar time. Development, though, is easier to provision and can use the results of an audit report to fix a concise set of issues. That model allows for teams to be spun up faster – generally Level Access recommends a budget of 120 hours of training and managed remediation work to get someone up and running.

As an example, if an application has two hundred operable screens and a relatively straightforward user-interface implementation a good estimate would assume around 2,400 hours to fix the application. With a dedicated team of two, an application could likely be brought into compliance in around nine calendar months accounting for the front end time to get the team provisioned, QA cycles and project management overhead. The work would be spread across a development team, around 70% of the work, and backed by a QA team auditing the fixes, around 30% of the work.

Level Access also recommends remediated products complete a standard QA cycle from the application business owners to make sure the accessibility changes have no impact on business function. Most modern development cycles have good separation of function between user interface, business logic, and data persistence layers. This allows accessibility changes to be made largely at the user interface layer with a high degree of isolation from other code. In practice, however, applications always have a mix of business logic and user interface function and it’s wise to validate business function after any remediation project.

Costs for remediation scale more or less linearly.  The larger the application there are some marginal returns to scale that drop the incremental cost of fixing additional system components. As the application gets smaller, the costs scale down but the fixed costs of provisioning, overhead, and QA start to dominate total costs under about one hundred pages or screens and things grow more constant.

With all that in mind, it is worth noting that Level Access has seen remediation projects take as little as three months to as long as ten years. So while rough estimates can be made, ultimately the exact time will vary based on the system and accurate estimates require an informed, system-specific approach.