WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Remediation Cost Versus Inclusive Design Cost

for

From: Brandon Keith Biggs
Date: Sep 13, 2017 3:19AM

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
>
>