E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Steffi Rausch
Date: Sun, Aug 11 2002 12:54AM
Subject: best screen readers for browser testing
No previous message | Next message →

I am a webmistress and web designer who is investigating different screen
readers to buy for the purpose of testing accessibility on our websites.
Price is also a factor of course. I like IBM Home Page Reader but am worried
that it is not that common. Should my company buy this $200 program just for
testing websites or should they go for the more expensive Window-Eyes or
JAWS since they are the most commonly used? Any suggestions would be greatly
appreciated. Thanks in advance.

Steffi Rausch
RESI, Jr. Web Developer
410-704-2063

"Design is intelligence made visible." - Rick Eiber


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: John Foliot - bytown internet
Date: Tue, Jun 18 2002 8:42AM
Subject: RE: best screen readers for browser testing
← Previous message | Next message →

Since the goal of true accessibility is that it *shouldn't* matter what user
agent you are using, then the choice conceivably becomes easier... if you
are simply testing web sites for accessibility, any text to speech browser
should suffice. Developers on a budget (aren't we all?) can even download a
FREE speech browser from Simply Web Talker (http://www.econointl.com/sw/)
While it lacks many of the bells and whistles of more expensive programs, it
does what it advertises it will do - render HTML documents to speech, warts
and all.

IBM Homepage Reader is a great program, and the browser has one of the best
implementations that I am aware of for LONGDESC. If the budget allows, grab
it, as testing across multiple user agents is regretably still one of the
things we as developers must do.

HTH

JF


>

From: Holly Marie
Date: Tue, Jun 18 2002 9:13AM
Subject: Re: best screen readers for browser testing
← Previous message | Next message →

----- Original Message -----
From: "John Foliot - bytown internet"

| Since the goal of true accessibility is that it *shouldn't* matter
what user
| agent you are using, then the choice conceivably becomes easier... if
you
| are simply testing web sites for accessibility, any text to speech
browser
| should suffice. Developers on a budget (aren't we all?) can even
download a
| FREE speech browser from Simply Web Talker
(http://www.econointl.com/sw/)
| While it lacks many of the bells and whistles of more expensive
programs, it
| does what it advertises it will do - render HTML documents to speech,
warts
| and all.


Good info and thanks, which brings thoughts all back to the point, if we
test items on the least supportive device, then we should or should not
expect other users of other devices and their support to be the rules by
which to write web page markup? Meaning... Jaws, and others may have
better support for table reading, forms, javascript, etc... though we
cannot apply that as the common rule and really might be better off
going with the lowest common denominator regarding accessible content.

I have yet to see any good stats on what devices are being used by whom.
On which OS, with what browsers, and versions.

How many fully blind are accessing the web, how many with low vision...
how many with color vision differences, etc...
How many other populations are accessing the web, cognitive, hearing,
aging, etc...
What the projected changes may be? Or comparisons of these numbers over
a few time slots alongside the numbers of average users without special
needs.

And though those stats are not directly important to accessible content,
meaning we really all ought to design fully accessible pages across as
wide an audience as possible.... those stats are really very important
to present the case and issue to others designing or needing web sites.
They need to know there is a good size of visiting populations out there
that may be even more dependent on Internet content[commercial,
educational, informational] than the average user. An average user has
many other options for information, the web may be a very important
extra option for information of every kind for special users or even
homebound users, workers, or learners. And not everyone will have the
tools with all the bells and whistles. So it may be better to test pages
with the least?

We need to appeal to the corporations, small businesses, public
services, and educational groups. There are many that have no idea about
these levels of use at all.


| IBM Homepage Reader is a great program, and the browser has one of the
best
| implementations that I am aware of for LONGDESC. If the budget
allows, grab
| it, as testing across multiple user agents is regretably still one of
the
| things we as developers must do.

John, I do not have home page reader, yet, I am very curious how the
reader implements the LONDESC.
Exactly how does that work? From my understanding of this LONGDESC
attribute, it is to be coded with a URI/URL between the quotes, and by
some type of Magic[?} the user that needs this is transported to that
area or page for the long description or information.

In some ways, I WANT to know how this is to work for the non device
user?

How does LONGDESC work for those that are able to see, and need a better
explanation of a chart or graph or any other item... map, schematic,
diagram, etc... Now we are talking about people outside that visual need
scenario, but may have other special needs or even, none at all. Maybe
this would be useful for many learning environments as an additional aid
or tool, or even for the normal public.

So, will LONGDESC be something that will work for all, and not just a
few, and exactly how is it to be implemented across all deliveries?

holly



----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Mark Rew
Date: Tue, Jun 18 2002 10:41AM
Subject: Re: best screen readers for browser testing
← Previous message | Next message →

STeffi,

Jaws and Window eyes is allot of money for strictly testing. For
accessibility testing use a combination of Lynks, Opra, and validation tools.
A package like Jaws will not help you much if you do not really understand how
a screen reader user navigates.

Mark
----- Original Message -----
From: "Steffi Rausch" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, June 18, 2002 10:37 AM
Subject: best screen readers for browser testing


> I am a webmistress and web designer who is investigating different screen
> readers to buy for the purpose of testing accessibility on our websites.
> Price is also a factor of course. I like IBM Home Page Reader but am worried
> that it is not that common. Should my company buy this $200 program just for
> testing websites or should they go for the more expensive Window-Eyes or
> JAWS since they are the most commonly used? Any suggestions would be greatly
> appreciated. Thanks in advance.
>
> Steffi Rausch
> RESI, Jr. Web Developer
> 410-704-2063
>
> "Design is intelligence made visible." - Rick Eiber
>
>
> ----
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>
>


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Lee Davis
Date: Wed, Jun 19 2002 2:41AM
Subject: Re: best screen readers for browser testing
← Previous message | No next message

Hi All

Various people wrote:
>Jaws and Window eyes is allot of money for strictly testing. For
>accessibility testing use a combination of Lynks, Opra, and validation tools.
>A package like Jaws will not help you much if you do not really understand how
>a screen reader user navigates.

>The reality of
>the situation at this point is that you need to test with one or more AT
>software programs, in my opinion.

The software is expensive but one of the problems we have is persuading web
developers that
there is a problem at all. Hence why we need to get them using something to
check their
pages. On the other hand, as you say, JAWS et al need experience and a lot of
use before you can really get anywhere.

IBM HPR is a middle route as it is easy to use and does help demonstrate
problems
quite nicely. On the other hand I agree that we should not rely on one
piece of software
as being a 'standard'. It may well be that HPR is the easiest thing to use
for web developers
to use for testing but is perhaps not the most common program used by the
disabled. So
we could end up with the situation where pages seem fine in HPR but not JAWS!

Another issue that bugs us is exactly how far we need to go; true - pages
should be designed
with universal accessibility but, surely, only to the extent that we know
of that causes problems.
For example, all this linearising of layout tables stuff. We used to be
told that screen readers
simply read *across the screen, line by line* but this is no longer true,
is it? Most AT programs
now read *cell by cell* don't they? Lynx, HPR etc do this, so are layout
tables actually
as problematic as they once were?

I think the following is a good discussion of tables:

http://oc.nci.nih.gov/web508/tip4.html

Should there not also be some onus on heavy users of AT programs to keep
their software up to date?


Lee

=======================================================================Lee Davis, IT Services, University of Exeter
Email: = EMAIL ADDRESS REMOVED =
Tel: +44-(0)1392-263960
Fax: +44-(0)1392-211630
WWW: http://www.exeter.ac.uk/
Post: Laver Building, North Park Road, Exeter, Devon, EX4 4QE, UK.
=======================================================================

----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/