E-mail List Archives
Re: Remediation Cost Versus Inclusive Design Cost
From: Bryan Garaventa
Date: Sep 12, 2017 5:47PM
- Next message: vennila murugesan: "Testing PDfs for accessiblilty"
- Previous message: JP Jamous: "Re: Remediation Cost Versus Inclusive Design Cost"
- Next message in Thread: Brandon Keith Biggs: "Re: Remediation Cost Versus Inclusive Design Cost"
- Previous message in Thread: JP Jamous: "Re: Remediation Cost Versus Inclusive Design Cost"
- View all messages in this Thread
In regard to Judith's original question:
"I have been researching this topic, but couldn't find anything useful. I'd like some information on how much it would cost to perform assessment and remediation on a project versus using inclusive design at the wireframe. My goal is to find evidence that implementing accessibility at the start of a project is cheaper than going through evaluation and remediation."
I can't provide direct information regarding monetary cost, however I can provide firsthand experience regarding time and effort expenditures that relate to your question.
Back in 2009, I started building the AccDC API at WhatSock.com with the goal of creating an accessible framework and dynamic content rendering system that would start out being as accessible as possible from the outset, in one part to also prove that if you begin with a baseline state like this, that full customization and updating is infinitely easier and cheaper than trying to take a fully built system that is not accessible and attempting to force accessibility into it.
Being blind though my visual design capabilities are somewhat lacking and the visual experience sort of sucked, so after a while of building most of the widgets and backend wireframes including the AccDC TSG and AccDC Bootstrap modules, the Accessibility Tree Training Guide, The ARIA Role Matrices, and Visual ARIA, I asked publically for help in restyling all of these things to make them visually more appealing.
This is the opposite of where most frameworks and libraries are coming from, which is to go from a fully visual baseline and a desire to force them to become accessible. In contrast, I already knew that besides the normal bugs cropping up here and there, what I had built was already accessible to start with, so the issue here was to see if it were possible to take fully accessible widgets and fully customize them and to see how easy it would be to do this.
This was no small task, the AccDC TSG archives alone have three versions, one powered by jQuery, another powered by MooTools, and another powered by Dojo, and all include mirror widgets for each that include hundreds of accessible widget wireframes, not counting the landing pages for the documentation which often makes use of these same widgets, plus the four different variants of WhatSock.com that includes versions powered separately by a standalone AccDC API version plus the other libraries mentioned above as testing mirrors, plus the same for the AccDC Bootstrap single page application that includes fourteen of these accessible widgets built into the landing page for testing when powered separately by all of the above libraries and frameworks as mirrors, plus the other educational resources like the Accessibility Tree Training Guide, ARIA Role Matrices, and Visual ARIA, all of which needed to be restyled individually. My point being, that this commitment would include remaking the visual layouts of thousands of differing combinations, and the testing of these combinations within different browsers across multiple devices ranging across both desktop and mobile.
A brilliant visual designer named Angela Ricci volunteered to do this, which she accomplished in total within approximately six months. Her efforts are described in more detail in the article at:
https://www.linkedin.com/pulse/how-true-functional-accessibility-scales-credit-angela-garaventa/
So regarding time cost to effort requirements, during the process of testing all of these widgets and interactive design patterns, she discovered approximately 4 JavaScript scripting issues, several suggestions to improve the visual experience, and introduced just a few places where I needed to update the accessibility scripting to make sure that the markup change matched the accessible usage of the feature. This last one mainly had to do with updating the skip links on the landing pages which was a simple fix.
So the time that I required to spend personally in fixing the discovered issues that cropped up during the six months that she was changing all of the visual layouts and visual cross browser compatibility issues for all of these widgets as she was working on them, added up to approximately 2 days' work on my part. So as far as cost goes, that's about 2 days' worth of wages for me.
In doing this, I proved that it is monumentally cheaper to update technologies that are already accessible to start with, than it is to totally revamp technologies that are not.
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com
- Next message: vennila murugesan: "Testing PDfs for accessiblilty"
- Previous message: JP Jamous: "Re: Remediation Cost Versus Inclusive Design Cost"
- Next message in Thread: Brandon Keith Biggs: "Re: Remediation Cost Versus Inclusive Design Cost"
- Previous message in Thread: JP Jamous: "Re: Remediation Cost Versus Inclusive Design Cost"
- View all messages in this Thread