Re: Question out of ignorance

The need for this kind of information in developing business cases in industry
is critical.  If I go to upper management and say, we need to make this web site
or web application accessible, they want to know how many people with
disabilities will use the site.  They also want a cost benefit analysis to
compare the cost of making a site accessible to the benefits we would
experience.  I bring out the point that there are legal issues, rework costs,
loss of customers, ADA compliance issues, need to support other means for
customer to contact us, etc., that also constitue real costs, but they still wnt
to know how many users there are who need accessibility, and what would kind of
customers they would be if the site were accessible (there is a myth that people
with disabilities don't buy services at a rate that would offset the cost of
making the site accessible, or don't making the purchasing decisions in their
households.)  We need some firmer numbers to support a business case, for
example:
how many potential web customers do we have who use accessibility devices or
enhancements,
what kind of customer are they (do they buy our enhanced services),
will they use a web site to do business or would they rather use the telephone.
I have made the case that making web sites accessible doesn't cost much if done
initially, and that users without disabilities don't even have to know about it,
and it doesn't mean boring low-tech pages, but they really don't believe it!
Since we serve essentially the entire public as our customers, the numbers for
my business case should be available but they aren't!
Lila


Al Gilman wrote:

> At 09:15 AM 2000-08-30 -0700, you wrote:
> >Al,
> >Do you have any information on the scope and numbers of people using
> >Accessibility devices on the Internet?
>
> PS: EO:  This is a frequently asked question.  If we had a FAQ linked from
> the WAI home page header, we might want it to address this question.
>
>
> >THANX,
> >Larry Roberts
> >
> >WWW.Kindred-souls.org
> >(site under construction)
> >
> >-----Original Message-----
> >From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> >Behalf Of Al Gilman
> >Sent: Monday, August 28, 2000 4:37 PM
> >To: w3c-wai-ig@w3.org
> >Subject: Re: Question out of ignorance
> >
> >
> >[sent to Cassandra Thomas; here's a copy for the list, finally... -Al]
> >
> >At 03:16 PM 2000-08-28 -0400, you wrote:
> >>Hi!
> >>
> >>I work for a consulting group which offeres a web usability service. Part
> >of
> >>our service is of course we check to see if a web site is meeting W3C
> >>standards and whether a text-to-speech reader can navigate the site (sadly
> >>which i must say always seems to be no). I currently have the lab set-up
> >>using IBM homepage reader for our text-to-speech test - we also use Bobby,
> >>test i.e., netscape, opera,  use Lynx, etc. Is the IBM product the most
> >>representative product for this type of test? Is there a product more
> >people
> >>use or one that would be a more universal test of what most
> >>visually-impaired users rely on?
> >>
> >
> >As I understand it, running a screen reader to reproduce the actual
> >interface experienced by a screen reader user is a non-trivial skill.  It
> >takes some significant investment in learning the tool, and it doesn't
> >always give visual feedback on what the screen reader is doing.
> >
> >A significant virtue of HomePage Reader is that it is an easy way to
> >present what is going on with coordinated sight and sound.  pwWebSpeak is
> >also good in this regard.
> >
> >Lynx only gives you the sight, but using it is often enough to grasp the
> >issues underlying a potential screen-reader usability failure.
> >
> >What is important about all of these is that they show you the effect
> >within the rapid-fire interactive process of read a little, follow a link,
> >read a little, follow a link, etc.
> >
> >It may make more sense to get evaluation services applied to a sample of
> >your pages or questionable issues from people who are customary screen
> >reader drivers, than to try to make competent screen reader drivers out of
> >all the people engaged in evaluation.
> >
> >Unfortunately, there is no magic wand that, by one quick technique, gets to
> >everything you want to catch and explains what was wrong with what was
> >caught.
> >
> >Someone in your organization should be systematically comparing your
> >methods against the Techniques for Accessibility Evaluation and Repair
> >Tools (AERT) published as a working draft on 22 August 2000. Also refer to
> >the change log.  Start at <http://www.w3.org/WAI/ER/IG/#new> to find both
> >of these.
> >
> >This will give you a more fine-grained checklist you can run through and
> >ask "in our process, how are we providing an equivalent check?"  It makes
> >good sense to make Bobby and HPR, for example, the workhorses at the center
> >of your process; but you should understand when other tools might be
> >necessary and how to use them.
> >
> >By the way, the Evaluation and Repair group needs feedback from people like
> >you who are doing evaluations in a production environment, to see how
>
> >practical their suggested methods are.
> >
> >What do others think?
> >
> >Al
> >>thanks,
> >>Cassandra Thomas
> >>Research Associate
> >>Giga Information Group
> >>W.Phone 408-327-4337
> >>Cell 408-505-3887
> >>Voicemail 408-327-4357
> >>
> >>
> >>
> >

--
Lila Laux, PhD
Human Factors Engineering
Qwest Communications
1475 Lawrence St., Suite 210
Denver, CO, 80202
303 624 0503

Received on Thursday, 31 August 2000 11:29:58 UTC