Re: Was: What would a screen reader make of this?, now: user testing

At 06:03 AM 2001-06-15 , Jim Tobias wrote:
>Hi All,
>
>I agree with all of Marjolein's points about non-commercial sites.
>But we need to look at the reality of user testing of commercial
>sites: if it's done at all, it's done on a small scale.  Of the
>commercial sites I'm aware of, user testing amounts to nothing
>more than an afterthought; in one case, it involved 10 family
>members of the webweaver team!  Of course user testing should be
>expanded -- no one would argue against that, and it should include
>users with disabilities.  But to argue that right now companies
>should bring in dozens of folks with lots of screen reader experience
>flies in the face of current practice, which is why it's ignored.
>
>The origin of this thread was a proposal to develop a screen reader
>simulation tool.  I accept all the criticisms we've seen here about the
>imperfection of such a tool.  But face the fact that this is the number
>two request I hear from corporate webweavers.  Number one is the
>automatic de-barrierizer, the coding tool that miraculously removes
>all inaccessibility from websites.  I hope we all agree that it's
>more important to argue against that one!
>
>The screen reader simulation tool would point them in the right direction,
>no matter how imperfect it was.  There should be a similar WAP tool,
>a phone-access tool (different from the screen reader tool), and others.
>None of these tools can guarantee anything, they can just illustrate
>the problems and solutions.  If the only alternative is to read, digest, and
>internalize the WCAG, we're kinda sunk.
>

AG::

The situation is neither as rosy as "what they ask for" nor as bleak as what
you paint.

Just a few high spots from what exists today:

First off, we have to help them get real.  The tool they are asking for is
impossible.  There is no way to reproduce the eyes-free user experience
without
turning off the screen.  And there is no way to surf the web efficiently that
way without UI techniques that take a lot of training.  Today's screen readers
and web readers are the high water mark in exploring that tradeoff.  We aren't
going to leap that performance envelope any day soon just by wishing.

For a further development of this idea, here, check out

 HCI Fundamentals and PWD Failure Modes
 <http://trace.wisc.edu/docs/ud4grid/#_Toc495220368>http://trace.wisc.edu/d
ocs/ud4grid/#_Toc495220368

On the other hand, there is good news, too.  If they get and use Home Page
Reader, for example, they get a reasonable compromise between something they
can learn and something that will help them understand what the eyes-free user
is up against.  And it won't break a web developer's budget.  But just like
Bobby, it won't do the whole job, either.

If you familiarize yourself with the quality assurance practices of the EEOC
website or the State of North Carolina, for example, you will be armed with
what you need to counter-propose to industry types who ask for the moon a
Chinese Menu of concrete, implementable development and evaluation practices
which, if they do some from each column, will move the content onto the site
expeditiously with few residual gotchas in the live site.  

Our mission, should we choose to accept it, is to navigate the corner-turn
from
where they are saying "I need a tool that ..."  into where they are saying "I
_can_ deploy a coordinated pattern of practices (when and how to apply the
tools that do exist) to be followed by the information sources, the site
maintainers, the user testers, etc."

Spell checking should be done by those who understand the content.  Style
sheets by those who understand the frontier of implementation.  Etc.

There's no silver bullet that will just kill this problem dead if you shoot it
at any one spot in the life-cycle of web content.  But a systemic approach
built out of readily achievable practices will do a lot.

Al

>Jim
>
>
>Jim Tobias
>Inclusive Technologies
>tobias@inclusive.com
>732.441.0831 v/tty
><http://www.inclusive.com/>www.inclusive.com
>

Received on Friday, 15 June 2001 11:31:46 UTC