W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2000

Re: Question out of ignorance

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 28 Aug 2000 19:36:59 -0400
Message-Id: <200008282324.TAA194274@smtp2.mail.iamworld.net>
To: w3c-wai-ig@w3.org
[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
>
>       
> 
Received on Monday, 28 August 2000 19:23:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:49 GMT