E-mail List Archives

Search E-mail List Archives for

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

From: Cohen, Lisa A.
Date: Tue, Jun 18 2002 11:58AM
Subject: RE: best screen readers for browser testing
No previous message | Next message →

I'm a web developer who is charged with 508 compliance... The reality of
the situation at this point is that you need to test with one or more AT
software programs, in my opinion. In fact, two of the 508 requirements
mention assistive technology, and in software development, testing is tied
to requirements. In other words, when the requirement states that "the form
shall allow people using assistive technology to access the information,
fields and functionality...", then the only way to test that requirement is
to use assistive technology to test the forms.
Of course, there are a number of wonderful techniques references out (books,
courses etc.) which make recommendations on how to implement accessibility
requirements, but they naturally vary from source to source.
In the case of a government agency which has stated that JAWS (largest
market share) is the official standard screen reader, then you have no
choice but to test the 508 requirements with JAWS.
We also test with IBM Home Page Reader, but not as extensively.
Lisa


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

From: John Goldthwaite
Date: Wed, Jun 19 2002 4:07AM
Subject: RE: best screen readers for browser testing
← Previous message | Next message →

I agree with Lisa that to meet the functional provisions of Section 508 you
have to test with assistive technology. According to Freedom Scientific,
JAWS has over 75% market share and it maybe higher for federal agency
employees using Microsoft Windows. If all you are testing is webpages you
don't need to purchase JAWS, you can buy Connect Outloud for $249 which is a
'crippled' version of JAWS that only works with IE and Outlook.

Connect Outload info-

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

> In the case of a government agency which has stated that JAWS (largest
> market share) is the official standard screen reader, then you have no
> choice but to test the 508 requirements with JAWS.
> We also test with IBM Home Page Reader, but not as extensively.

ARGHHH!!!!!!

This sounds dangeously close to: "Since Internet Explorer has an 85% market
share then we have no choice but to test on IE. We also test on Netscape,
but not as extensively." (Never mind that there is also the versioning
issue to contend with...)

Freedom Scientific should be commended for developing and refining a great
piece of Assitive Technology, one which aids the visually impaired use
computers not only for accessing web content, but for all of the other
wonderful things we can do with these machines.

But to say that a web page has been tested in Jaws and it works "fine",
therefore it is <TaDa> accessible, is preposterous. Jaws is a screen
reader, not a SGML parser. Most North American Jaws users will access web
pages using a combination of Jaws and IE, so it would probably stand to
reason that if it "works" in IE, a screen reader would be able to access the
content.

Off list, I was told, as justification to get the latest and most *complete*
software "Without getting into technical details, no matter how compliant
your code is to the HTML 4.01 standard, some of these technologies just will
not interpret and communicate certain tags and information accurately or in
some cases not at all." No contest, but should we then continue to develop
to software instead of standards? Rubbish. Netscape 4.x will not interpret
some of the HTML 4.01 code either (Tabindex, Accesskey, Longdesc, etc.) so
should we not bother testing in Netscape 4.x? Or just not worry about adding
them? (LONGDESC in particular has very dodgy support - should we not bother
then?)

Folks, I'm not advocating NOT testing using AT, but reality check here, just
as you can never replicate every configuration of user agent and operating
platform for the sighted, you cannot replicate every conceivable situation
for the visually impaired (or the mobility impaired, or the cognitively
impaired, or the technology impaired... do you think every blind person out
there can afford to continually upgrade Jaws every time a new version comes
out?).

<mantra>
CODE TO THE STANDARDS, NOT TO THE SOFTWARE
</mantra>
To which I would add the WAI Guidelines as well.

The W3C provides a list of over 35 different "Alternative Web Browsers"
(http://www.w3.org/WAI/References/Browsing), including many text to speech
alternatives. To rely solely on Jaws to replicate the user experience is
then no more logical than relying solely on Internet Explorer on a Windows
system to exclusively replicate the user experience (with a 17" monitor set
at 1024 X 768, or wait, no, a 14" monitor at 800 X 600, or maybe....). But
if you have coded to the standards, then honestly, the software check should
almost be an afterthought (it isn't I know, but it should be...) And so,
Jaws, HPR, Window-eyes, pwWebspeak, Slimware Window Bridge; it shouldn't
matter. True, not all will support everything, but is that really any
different than what the rest of us have to deal with?

As always, JMHO

JF


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

From: Holly Marie
Date: Wed, Jun 19 2002 11:55AM
Subject: Re: best screen readers for browser testing
← Previous message | No next message

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

| <mantra>
| CODE TO THE STANDARDS, NOT TO THE SOFTWARE
| </mantra>
| To which I would add the WAI Guidelines as well.
|
| The W3C provides a list of over 35 different "Alternative Web
Browsers"
| (http://www.w3.org/WAI/References/Browsing), including many text to
speech
| alternatives

I agree.
Code to the standards, so when or where it works for various devices,
etc. It works.
Where it does not work, it still delivers as parsed or text only. And
there it is up to the devices or the user to learn how to use the
devices to access the pages that are marked up correctly.

What I would like to add, ... know which items do not have the best
support, and use acceptable alternatives that are marked up correctly in
the documents. [in the case of LONGDESC, it is or may still be necessary
to supply that extra "D" link, not only for non vision users, but also
for all others needing to access the information]. I feel the same way
regarding "Skip Links". This should be visible so that users with
mobility impairments, not able to use a mouse device, can access that
skip function also. There may be individuals with mobility impairments
like Cerebral palsy, that use devices for accessing pages, like sticky
keys, sticks, puff system, etc... that may not be able to read written
words. These users may understand or hear speech, and use screen readers
though they can see. So we really need to be aware of making pages
universally accessible, for a great variety of combinations and users.
These tools for one group can be used for other groups.

And lets not fall into the trap that accessibility is only about one
group. Or even the line of thought... the most serious, or largest
population is thus, and we will code for that. Ditto on the equipment.

holly



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