WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Remediation Cost Versus Inclusive Design Cost

for

From: Bryan Garaventa
Date: Sep 13, 2017 11:10AM

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 REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Brandon Keith Biggs
Sent: Wednesday, September 13, 2017 2:20 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost

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 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 REMOVED>
> 415.624.2709 (o)
> www.LevelAccess.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Tim Harshbarger
> Sent: Tuesday, September 12, 2017 5:29 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost
>
> 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.
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Meacham, Steve - FSA, Kansas City, MO
> Sent: Monday, September 11, 2017 4:54 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost
>
> 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."
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Tim Harshbarger
> Sent: Friday, September 08, 2017 12:40 PM
> To: <EMAIL REMOVED> ; WebAIM Discussion List <
> <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost
>
> 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
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Judith Blankman via WebAIM-Forum
> Sent: Friday, September 08, 2017 10:54 AM
> To: <EMAIL REMOVED>
> Subject: Re: [WebAIM] Remediation Cost Versus Inclusive Design Cost
>
> 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 REMOVED> >
> Date: Friday, September 8, 2017 at 8:52 AM
> To: " <EMAIL REMOVED> " < <EMAIL 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 REMOVED> > on behalf of
> JP Jamous < <EMAIL REMOVED> >
> Organization: Jepelsy
> Reply-To: " <EMAIL REMOVED> "
> < <EMAIL REMOVED> >
> Date: Friday, September 8, 2017 at 8:07 AM
> To: " <EMAIL REMOVED> " < <EMAIL 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
> > > archives at http://webaim.org/discussion/archives
> > <EMAIL REMOVED> >
>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
>
>
>
> This electronic message contains information generated by the USDA
> solely for the intended recipients. Any unauthorized interception of
> this message or the use or disclosure of the information it contains
> may violate the law and subject the violator to civil or criminal
> penalties. If you believe you have received this message in error,
> please notify the sender and delete the email immediately.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >