E-mail List Archives
Thread: Remediation Cost Versus Inclusive Design Cost
Number of posts in this thread: 16 (In chronological order)
From: JP Jamous
Date: Fri, Sep 08 2017 9:06AM
Subject: Remediation Cost Versus Inclusive Design Cost
No previous message | Next message →
Hi folks,
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.
Any help or references will be highly appreciated.
---
This email has been checked for viruses by AVG.
http://www.avg.com
From: Judith Blankman
Date: Fri, Sep 08 2017 9:52AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
I would be very interested in what you find, JP. We all know the pain, just need evidence to persuade others.
I have seen a graphic that illustrates the cost of defect fixing by stage that shows an increase 10 times exponentially.
I reached out to my colleague about where he found it and others like it. The graphic he sent to me is from a book 'Software Engineering- by Barry Boehm.
He suggests looking at the Software Engineering Institute. He also sent me this link: http://www.ieee.org/index.html and says that the IEEE standards drives the electronic/digital world.
Best,
Judith Blankman
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of JP Jamous < = EMAIL ADDRESS REMOVED = >
Organization: Jepelsy
Reply-To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
Date: Friday, September 8, 2017 at 8:07 AM
To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Remediation Cost Versus Inclusive Design Cost
Hi folks,
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.
Any help or references will be highly appreciated.
---
This email has been checked for viruses by AVG.
http://www.avg.com
From: Judith Blankman
Date: Fri, Sep 08 2017 9:54AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Additionally, the argument might not be specific to inclusive design.
I think the point of persuasion is to do things right the first time, which is what inclusive design leads to.
From: "Blankman, Judith A." < = EMAIL ADDRESS REMOVED = >
Date: Friday, September 8, 2017 at 8:52 AM
To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost
I would be very interested in what you find, JP. We all know the pain, just need evidence to persuade others.
I have seen a graphic that illustrates the cost of defect fixing by stage that shows an increase 10 times exponentially.
I reached out to my colleague about where he found it and others like it. The graphic he sent to me is from a book 'Software Engineering- by Barry Boehm.
He suggests looking at the Software Engineering Institute. He also sent me this link: http://www.ieee.org/index.html and says that the IEEE standards drives the electronic/digital world.
Best,
Judith Blankman
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of JP Jamous < = EMAIL ADDRESS REMOVED = >
Organization: Jepelsy
Reply-To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
Date: Friday, September 8, 2017 at 8:07 AM
To: " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Remediation Cost Versus Inclusive Design Cost
Hi folks,
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.
Any help or references will be highly appreciated.
---
This email has been checked for viruses by AVG.
http://www.avg.com
From: Tim Harshbarger
Date: Fri, Sep 08 2017 11:40AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
I think it is extremely tough to find stats specifically for accessibility or inclusive design.
You should be able to find stats on how much it costs to fix defects at various stages of a project (including post-implementation). I can't imagine there is a reason why addressing accessibility defects would have a significantly different cost than other defects like usability, functionality, or security. However, you might need to persuade your audience that accessibility defects aren't really any different than any other defect when it comes to repairing them. They all require that people have some level of knowledge about that type of defect in order to be able to identify and fix them. The more competent their knowledge level, the easier it will be to identify and fix the defect.
I think you should be able to prove that the cost of addressing defects in design and development are so much less than fixing them as part of remediation that there is no way you could ever run a remediation project for less than what it would have cost you to have addressed the defects during design and development.
Also, you might want to find examples where "remediation" can't fix the problem. That is the remediation needed to fix some problems can involve completely redesigning something from scratch.
Hopefully that helps somewhat.
Thanks,
Tim
From: Robert Fentress
Date: Fri, Sep 08 2017 12:18PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
These resources might provide some useful info, though I can't vouch for
how accessible they are themselves.
- IBM's WCAG 2.0 Compliance Costing Model
<https://www-03.ibm.com/able/education/downloads/IBM_WCAG_2.0_Compliance_Costing_Model_CSUN13.pdf>
- Cost Savings of Early Accessibility
<https://www-03.ibm.com/able/education/downloads/CostSavingsofEarlyAccessibility-CSUN-2012_accessible_IBM.pdf>
- Cost Case Studies of CampusWeb Accessibility
<http://ncdae.org/presentations/2013/CSUN/cost.pdf>;
On Fri, Sep 8, 2017 at 1:40 PM, Tim Harshbarger <
= EMAIL ADDRESS REMOVED = > wrote:
> I think it is extremely tough to find stats specifically for accessibility
> or inclusive design.
>
> You should be able to find stats on how much it costs to fix defects at
> various stages of a project (including post-implementation). I can't
> imagine there is a reason why addressing accessibility defects would have a
> significantly different cost than other defects like usability,
> functionality, or security. However, you might need to persuade your
> audience that accessibility defects aren't really any different than any
> other defect when it comes to repairing them. They all require that people
> have some level of knowledge about that type of defect in order to be able
> to identify and fix them. The more competent their knowledge level, the
> easier it will be to identify and fix the defect.
>
> I think you should be able to prove that the cost of addressing defects in
> design and development are so much less than fixing them as part of
> remediation that there is no way you could ever run a remediation project
> for less than what it would have cost you to have addressed the defects
> during design and development.
>
> Also, you might want to find examples where "remediation" can't fix the
> problem. That is the remediation needed to fix some problems can involve
> completely redesigning something from scratch.
>
> Hopefully that helps somewhat.
>
> Thanks,
> Tim
>
From: Robert Fentress
Date: Fri, Sep 08 2017 12:20PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Ha ha! I just noticed Tim is one of the presenters for one of these.
Small world.
On Fri, Sep 8, 2017 at 2:18 PM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> These resources might provide some useful info, though I can't vouch for
> how accessible they are themselves.
>
> - IBM's WCAG 2.0 Compliance Costing Model
> <https://www-03.ibm.com/able/education/downloads/IBM_WCAG_2.0_Compliance_Costing_Model_CSUN13.pdf>
> - Cost Savings of Early Accessibility
> <https://www-03.ibm.com/able/education/downloads/CostSavingsofEarlyAccessibility-CSUN-2012_accessible_IBM.pdf>
> - Cost Case Studies of CampusWeb Accessibility
> <http://ncdae.org/presentations/2013/CSUN/cost.pdf>;
>
>
> On Fri, Sep 8, 2017 at 1:40 PM, Tim Harshbarger <tim.harshbarger.cqwg@
> statefarm.com> wrote:
>
>> I think it is extremely tough to find stats specifically for
>> accessibility or inclusive design.
>>
>> You should be able to find stats on how much it costs to fix defects at
>> various stages of a project (including post-implementation). I can't
>> imagine there is a reason why addressing accessibility defects would have a
>> significantly different cost than other defects like usability,
>> functionality, or security. However, you might need to persuade your
>> audience that accessibility defects aren't really any different than any
>> other defect when it comes to repairing them. They all require that people
>> have some level of knowledge about that type of defect in order to be able
>> to identify and fix them. The more competent their knowledge level, the
>> easier it will be to identify and fix the defect.
>>
>> I think you should be able to prove that the cost of addressing defects
>> in design and development are so much less than fixing them as part of
>> remediation that there is no way you could ever run a remediation project
>> for less than what it would have cost you to have addressed the defects
>> during design and development.
>>
>> Also, you might want to find examples where "remediation" can't fix the
>> problem. That is the remediation needed to fix some problems can involve
>> completely redesigning something from scratch.
>>
>> Hopefully that helps somewhat.
>>
>> Thanks,
>> Tim
>>
From: JP Jamous
Date: Fri, Sep 08 2017 1:22PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Thank you all for the references. I know we all have been in the same boat. I am just trying to ensure my audience hit the recognition spot. I will try to persuade them in all types of ways.
From: Jennifer Sutton
Date: Fri, Sep 08 2017 2:39PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Greetings, all:
Karl Groves has posted quite a bit on this topic over the years, and
I'll include a few places to start, below.
Much of it is not time sensitive, in my view, but it's always a good
idea to look at dates.
Items are not in a particular order.
Best,
Jennifer
Blog category on the Business case:
http://www.karlgroves.com/category/accessibility-business-case/
How Expensive is Web Accessibility
http://www.karlgroves.com/2011/11/30/how-expensive-is-accessibility/
This is the beginning of a series -- New Series Coming Selling Accessibility
http://www.karlgroves.com/2012/06/27/new-series-coming-selling-accessibility/
Here's one in the series:
Selling Accessibility Framing the message
http://www.karlgroves.com/2013/08/02/selling-accessibility-framing-the-message/
From: Metzessible
Date: Sat, Sep 09 2017 10:20AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
If you rephrase the question a bit, it might be easier to find the answers
you're looking for. Remediation is generally done because one waited until
there was a problem in the first place. Whereas accessibility integration
is more about doing things as part of an overall process. A helpful google
search might be to look at these different approaches in terms of project
management: Is Agile more cost effective than Waterfall?
Unfortunately, I don't have any hard stats. But from an armchair
perspective, it seems like most accessibility experts are hired when a
company or agency has been called out for not doing something, instead of
approaching the solution from the start of a project or requirements
gathering session. And speaking as a PDF subject matter expert, I can tell
you that I'm only called in when things are really bad. I was hired at my
last job because 1000 heavily designed untagged PDFs were created for a
government project and no one apparently read that part of the FAR.
I wrote about this last year on Medium, actually:
https://medium.com/@jonbmetz/accessibility-is-a-process-not-a-project-ce1c1cdc3aa7
Thinking of it another way, go build a permanent structure in your
backyard, and then go through the process of getting permits and
inspections. Does it cost the same after you've already finished your
awesome garage workshop and have to make alterations because you didn't do
something up to code?
Hope you find the answers you're looking for.
On Fri, Sep 8, 2017 at 4:39 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings, all:
>
>
> Karl Groves has posted quite a bit on this topic over the years, and I'll
> include a few places to start, below.
>
> Much of it is not time sensitive, in my view, but it's always a good idea
> to look at dates.
>
>
> Items are not in a particular order.
>
>
> Best,
>
> Jennifer
>
>
> Blog category on the Business case:
>
> http://www.karlgroves.com/category/accessibility-business-case/
>
>
> How Expensive is Web Accessibility
>
> http://www.karlgroves.com/2011/11/30/how-expensive-is-accessibility/
>
>
> This is the beginning of a series -- New Series Coming Selling
> Accessibility
> http://www.karlgroves.com/2012/06/27/new-series-coming-selli
> ng-accessibility/
>
> Here's one in the series:
> Selling Accessibility Framing the message
> http://www.karlgroves.com/2013/08/02/selling-accessibility-
> framing-the-message/
>
> > > > >
From: Meacham, Steve - FSA, Kansas City, MO
Date: Mon, Sep 11 2017 3:53PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
At the risk of sounding cynical, an argument can be made that literally doing nothing (pre or post implementation) may be cheaper than doing something (again, pre or post implementation). My experience is that organizations that are uninterested in doing the first tend to be just as uninterested in doing the second. Note I say "doing" rather than "talking about."
From: Tim Harshbarger
Date: Tue, Sep 12 2017 6:28AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
That is a valid statement. It might be easy enough to redirect such a statement to a more meaningful discussion.
It is cheaper to make apps insecure than it is to make them secure.
It is cheaper to do no testing than it is to do testing.
It is cheaper to provide no customer support than it is to provide customer support.
It is cheaper not to develop web or native mobile applications than it is to develop them.
Most people would disagree with the above statements. Why is that? That is because each of those things has a value beyond the doing. Testing for the sake of testing has no value. People value testing because of the value it provides afterwards.
It is very likely to be cheaper not to include any alt text than it is to write alt text for images. That is also true for every other part of design and development work--and yet we do them.
Since we agree that there is little value in doing a thing just to do it, it appears that the best way to determine whether or not we should be doing accessibility is to discuss what value accessibility has to us.
And if you can get your audience to start discussing the value of accessibility to their organization, then I think you can start having a meaningful discussion that likely will lead somewhere.
That doesn't mean they will start by agreeing with you. But if they do not agree, it helps to understand why they disagree if you have any hope of persuading them.
Just a thought.
From: Peter Shikli
Date: Tue, Sep 12 2017 1:46PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Getting back to the original question, which I find quite relevant because
of the justification I hear all the time, "Let's talk accessibility after
the redesign is complete." My response is always the question, "When has
your website not been in the middle of a redesign?"
As you can see from the respondents to this blog, the arguments for
including accessibility in a (re)design are qualitative, not quantitative,
which number-crunching decision makers find less compelling. They are
after all risk-averse folks unhappy with changing plans.
The reason for the absence of reports with the quantitative support that
Jim is looking for is because so many factors need to be considered on a
case-by-case basis, some with no quantitative impact in one case and the
same factor with a huge impact in another case.
To overcome this, I propose the development of a spreadsheet model that
trades off all the different factors with quantitative values decision
makers can put in themselves on a case-by-case basis. Such a model can
then be used to analyze what-if scenarios in the classical sense of a
cost-benefit analysis.
Rather than leave this as a suggestion for others, I would like to convert
this forum question into a call for a team of volunteers, myself included,
to develop such a model. We have a couple of talented Excel jockeys here.
What we would need to start out would be a list of quantifiable costs and
savings to integrate into the model. With that, I would present a
first-draft of the model on a collaborative site for team feedback.
To proceed, I would need two kinds of respondents to = EMAIL ADDRESS REMOVED = ,
one to say they would like to be on the development team, and another to
say they would use such a spreadsheet model if it were available at no
cost. I will gauge my interest in proceeding by that response.
Cheers,
Peter Shikli
From: JP Jamous
Date: Tue, Sep 12 2017 3:04PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
I like Peter's idea. Do we have any participants? I am already in since this is a very important topic for me.
From: Bryan Garaventa
Date: Tue, Sep 12 2017 5:47PM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com
From: Brandon Keith Biggs
Date: Wed, Sep 13 2017 3:19AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | Next message →
Hello Bryan,
Did you document techniques that both you and Angela did that worked
particularly well and things you both did that didn't work as well?
This design paradigm is creating a screen reader friendly site first, then
updating the visual UX to be much better after the site has been developed.
What did you do from a technical standpoint? How did you design your
widgets so they could have visual styling most effectively applied? Did you
use any CSS to begin with? How detailed can one get the visual UI with CSS
before needing a redesign of the widgets?
Your experience is invaluable to helping blind front-end developers design
most effectively.
I'm not sure that 6 months of a visual developer's time is something most
blind people have access to, so it would be interesting if there were ways
to reduce this time through design of CSS classes and positioning of
widgets.
What your case study goes to prove is that screen reader accessibility is
much more fundamental to the initial design than visual accessibility is. I
would love to know what Angela's workflow looked like and where she did
most of her changes.
Thanks,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
On Tue, Sep 12, 2017 at 4:47 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.LevelAccess.com
>
>
From: Bryan Garaventa
Date: Wed, Sep 13 2017 11:10AM
Subject: Re: Remediation Cost Versus Inclusive Design Cost
← Previous message | No next message
Actually at the time I was just grateful that somebody was willing to help out like this, so I didn't really consider the process, since I had never done it before, there actually was no process. We basically worked out a game plan and I followed her lead in whatever she wanted to work on first and we moved on from there. Since then she has moved onto other projects, but you are welcome to contact her to ask about her experience, her personal website is here http://gericci.me/
Probably the most useful thing that I discovered during the process, was that there is a significant difference between the concept of functional accessibility versus visual accessibility. Visual accessibility being what people expect to happen based on visual information and how this relates to the underlying code. People often confuse these things and incorrectly believe they are the same thing.
Functional accessibility is totally unrelated to the visual aspect, and is only tied to it loosely in some cases where the two are intrinsinctly bound together. E.G Such as when visual components only appear when focus is set on a particular component like in the case of an auto suggest combobox, etc.
So in most cases at the basic level when styling is not required, functional accessibility works correctly for both screen reader and keyboard only users without a screen reader even when there is no styling applied at all, essentially creating a blank canvas for visual designers to do anything they wish to it using CSS without negatively affecting the accessibility of the widget for either of these user groups. There are of course somethings that CSS will do if misapplied that will introduce issues, but I found that these are easily tested for and corrected during the process of development because it's just a matter of tweaking the code within the style sheet or making slight updates to the widget functionality in some rare cases to achieve a particular affect. Typically this takes very little time and effort to achieve.
So the best starting point is to first achieve full functional accessibility, then apply visual styling later to cover varying circumstances if you don't want to have to keep recreating the same wheels for every differing product. Often the only thing that is different is what it looks like, the basic underlying functionality typically remains consistent.
Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com