WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Monitoring JAWS adoption trends for testing/support

for

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

From: cpavradopoulos@checkfree.com
Date: Tue, Feb 20 2007 4:10PM
Subject: Monitoring JAWS adoption trends for testing/support
No previous message | Next message →

I am a newbie to this forum and looking for input on JAWS support. My
company has decided to test and support only 1 screen reader, and that is
JAWS. The problem comes when deciding which version to test. For browser
support, we meet monthly to review stats from Web Trends, along with
industry stats to make data-driven decisions. Since this data does not
appear to exist (anywhere that I have looked thus far) for screen readers,
we want to determine if there is an alternate way to track adoption trends
for JAWS users. Freedom-Scientific has not been helpful thus far (their
recommendation is to always use the latest and greatest). So if I know
that last month the stats looked like this:

v8.xx 10%
v7.xx 55%
v6.xx 10%
other 25%

We would only test/support v7.xx. Then next month, if it changes to:

v8.xx 50%
v7.xx 35%
v6.xx 10%
other 5%

We would switch to v8.xx and drop support of v7.xx.

Thanks in advance for any guidance you can provide.

Costa Avradopoulos
Manager, Software Quality
Ecommerce - Product Development
= EMAIL ADDRESS REMOVED =

CheckFree. The business of money uncomplicatedSM.
http://www.checkfree.com

From: Alastair Campbell
Date: Wed, Feb 21 2007 3:00AM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | Next message →

Costa Avradopoulos wrote:
> data does not appear to exist (anywhere that I have looked
> thus far) for screen readers,

Hi Costa,

In five years of keeping an eye out for that kind of data, I have yet to
find a source.

In retrospect, I actually think this is a good thing, for exactly the
reasons your company wants this data:

> My company has decided to test and support only 1 screen reader,
> and that is JAWS.

Although it's good that your company is checking for accessibility,
using a particular user agent (screen reader in this case) to make
decisions can do more harm than good, especially if you are not a
regular user of that technology.

There are hundreds of possible technologies that people can use, each
with their own interaction style. Using only one could lead you to make
design choices in one particular way. That way may not help people using
other technologies.

Hopefully I'm not stating the obvious, but that is why the W3C created
the guidelines [1], which even after 8 years are still a pretty good way
of improving the accessibility of a web site. (Although I generally
consider most of the 'until user agent' ones not applicable anymore.)

In terms of your goals, I would try and fulfil them with:
1. An initial scoping exercise after reading the guidelines, that leads
to carefully considered changes.
NB: Read about the techniques as well as the guidelines [3]).

2. Creating a prototype or set of templates based on those changes
that you test with:
a. Technical checks against the guidelines [2].
b. Any available user-agents, preferably with people that use
them day-to-day.

I know that's not quite what you asked for, but I hope it helps...

Kind regards,

-Alastair

1. http://www.w3.org/TR/WCAG10/full-checklist.html
2. http://www.webaim.org/articles/evaluatingwithfirefox/
3. http://www.webaim.org/articles/


Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Léonie Watson
Date: Wed, Feb 21 2007 3:20AM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | Next message →

Alastair Campbell wrote:

"There are hundreds of possible technologies that people can use, each with their own interaction style. Using only one could lead you to make design choices in one particular way. That way may not help people using other technologies."

I'd absolutely agree with Alastair's comments and add to them by saying that one person may use multiple access technologies. I use different versions of Jaws for different tasks, I sometimes use a different screen reader all together.

Designing for just one version of one specific access tech can very easily become counter productive from the user's point of view.

Regards,
Léonie.



-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Alastair Campbell
Sent: 21 February 2007 09:49
To: WebAIM Discussion List
Subject: Re: [WebAIM] Monitoring JAWS adoption trends for testing/support

Costa Avradopoulos wrote:
> data does not appear to exist (anywhere that I have looked thus far)
> for screen readers,

Hi Costa,

In five years of keeping an eye out for that kind of data, I have yet to find a source.

In retrospect, I actually think this is a good thing, for exactly the reasons your company wants this data:

> My company has decided to test and support only 1 screen reader, and
> that is JAWS.

Although it's good that your company is checking for accessibility, using a particular user agent (screen reader in this case) to make decisions can do more harm than good, especially if you are not a regular user of that technology.

There are hundreds of possible technologies that people can use, each with their own interaction style. Using only one could lead you to make design choices in one particular way. That way may not help people using other technologies.

Hopefully I'm not stating the obvious, but that is why the W3C created the guidelines [1], which even after 8 years are still a pretty good way of improving the accessibility of a web site. (Although I generally consider most of the 'until user agent' ones not applicable anymore.)

In terms of your goals, I would try and fulfil them with:
1. An initial scoping exercise after reading the guidelines, that leads to carefully considered changes.
NB: Read about the techniques as well as the guidelines [3]).

2. Creating a prototype or set of templates based on those changes
that you test with:
a. Technical checks against the guidelines [2].
b. Any available user-agents, preferably with people that use
them day-to-day.

I know that's not quite what you asked for, but I hope it helps...

Kind regards,

-Alastair

1. http://www.w3.org/TR/WCAG10/full-checklist.html
2. http://www.webaim.org/articles/evaluatingwithfirefox/
3. http://www.webaim.org/articles/


Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html

From: Robinson, Norman B - Washington, DC
Date: Wed, Feb 21 2007 9:20AM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | Next message →

For my two cents, we currently still test and use only version 6.X.

We have a locked-down environment and only provide our official screen
reader to users unless they have a specific individual accommodation
need for a newer version. We would purchase a license for 8.X (what the
vendor sells) and use 6.X; the vendor doesn't understand our business
need for this support, but it is required in our environment.

That said, we've been keeping track of updates and will be evaluating
8.X as our official version soon. Also, since we use more than one
operating system we will be considering adding Linux specific screen
reader(s) in our next policy update
(http://www.usps.com/cpim/ftp/hand/as508a/508a_c3.html#Iv8D11399mudg)

We have so many web based applications and software applications that
moving to "the latest version" is difficult and costly. Added to our
desktop environment where users cannot install software that requires
administrative rights and it becomes technically difficult. We've found
that our public users also benefit from applications that we know work
with a version (or two) behind. We can draw some accurate assumptions
that if it works in a previous version of JAWS that is works in the
current version.

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Tuesday, February 20, 2007 6:04 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Monitoring JAWS adoption trends for testing/support


I am a newbie to this forum and looking for input on JAWS support. My
company has decided to test and support only 1 screen reader, and that
is
JAWS. The problem comes when deciding which version to test. For
browser
support, we meet monthly to review stats from Web Trends, along with
industry stats to make data-driven decisions. Since this data does not
appear to exist (anywhere that I have looked thus far) for screen
readers,
we want to determine if there is an alternate way to track adoption
trends
for JAWS users. Freedom-Scientific has not been helpful thus far (their

recommendation is to always use the latest and greatest). So if I know
that last month the stats looked like this:

v8.xx 10%
v7.xx 55%
v6.xx 10%
other 25%

We would only test/support v7.xx. Then next month, if it changes to:

v8.xx 50%
v7.xx 35%
v6.xx 10%
other 5%

We would switch to v8.xx and drop support of v7.xx.

Thanks in advance for any guidance you can provide.

Costa Avradopoulos
Manager, Software Quality
Ecommerce - Product Development
= EMAIL ADDRESS REMOVED =

CheckFree. The business of money uncomplicatedSM.
http://www.checkfree.com

From: Joseph O'Connor
Date: Wed, Feb 21 2007 2:20PM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | Next message →

On Feb 21, 2007, at 11:00 AM, = EMAIL ADDRESS REMOVED =
wrote:

> From: = EMAIL ADDRESS REMOVED =
> Date: February 20, 2007 3:04:29 PM PST
>
> I am a newbie to this forum and looking for input on JAWS support. My
> company has decided to test and support only 1 screen reader, and
> that is
> JAWS.

Costa,

At the risk of enduring a firestorm of opprobrium:-)

I highly recommend Fangs for Firefox.

Fangs (text based screen reader emulator)
http://www.standards-schmandards.com/projects/fangs

Fangs takes a page and outputs it as text in the form that screen
readers would read your page. JAWS output is ephemeral. When JAWS is
done reading a page, you aren't left with anything concrete, and
while you are reading the page you have to pay close attention to
listen for things that should be there and notice when things that
shouldn't be there are present.

This is NOT to say that Fangs is a replacement for JAWS. I use both.
One place that Fangs shines is that Fangs output is easily
understandable by just about anyone, and the output can be copied and
pasted into an email or saved and read at a later date.

I recently collaborated with a coder on a project to build a
calendaring system. I went to the calendar page, ran Fangs on it,
copied the text and emailed it to the coder. I got a call telling me
that "now she understood the problems" because it was there in text
in front of her. Not so easy with JAWS, grasshopper:-)

Oh, and aside from a possible PayPal donation to Peter Krantz, Fangs
is free!

Joseph O'Connor
CSUN Manager University Web Communications

From: cpavradopoulos@checkfree.com
Date: Thu, Feb 22 2007 3:40PM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | Next message →

Thank you very much Alastair, Lonie, and Norman for your responses.

Alastair: We do in fact use a layered approach to our Dev/Testing by
having a Developer run Bobby against the code (1st layer) to catch most of
the low hanging fruit, and then some, looking to bake accessibility into
the product before it even gets to QA. The JAWS testing my team does is
primarily to test the user experience, and secondarily accessibility, as a
check and balance for the work Dev does.

Norman: You made a comment that you stay behind a version or 2 on purpose
because if it works in an older version, it must work in a newer one. I
actually thought the same thing, but what is interesting (and quite
ironic) is that I had a production trouble ticket come to me today with a
user complaining about issues using JAWS 7.1. Apparently our App Support
person told the user to just downgrade to v6.1, which is what we currently
test and support for our product, and of course the user refused. I am
going to have to dig into the specifics of the issue... maybe it's just an
isolated case and exception to the rule?

I understand what everyone is saying about using and testing different
technologies, but the truth is when you have extremely limited resources,
and can only support 1 version, you are forced to go with the majority (if
anyone can ever figure that out).

Thanks

Costa Avradopoulos
Manager, Software Quality
Ecommerce - Product Development
= EMAIL ADDRESS REMOVED =

CheckFree. The business of money uncomplicatedSM.
http://www.checkfree.com

From: Robinson, Norman B - Washington, DC
Date: Mon, Feb 26 2007 11:50AM
Subject: Re: Monitoring JAWS adoption trends for testing/support
← Previous message | No next message

Costa,

Yes. We have had discussed such issues, specifically with JAWS
7.X and when upgrading from versions to versions. Screen readers are
software. The vendor produces new versions and break things, as well as
they try to adapt to the changing environment of the operating system
itself. I have seen newer versions of the software that didn't provide
the same degree of access, but consider those defects in the screen
reader. That still required the vendor to issue a patch or upgrade their
screen reader or self-contained scripts.

As to users versus testing: if you don't control your users
selection of technologies then you will encounter incompatibilities. The
only approach you can take is somewhat hostile to the end-users; declare
an officially supported version and thus encourage them to use that
version, else they don't get the same level of support. This gets
particularly awkward when users have the expectation that the software
is required for basic access. This is usually true, but in the same way
that organizations standardize on one word processor, you can have more
quality controls if you have consistency by either establishing one
version or establishing standards all versions must comply with to be
supported.

That isn't to say I don't side with the user! The user needs
access and generally speaking the newer versions are 'better'. However,
if you trust the vendor's newest version is better based on the vendor's
recommendation alone, then you better ensure the vendor is going to
support you. As far as I know, they'll never do that without a formal
contractual arrangement and no matter how much you love your vendor,
you'll be better off building the expertise in-house.

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Thursday, February 22, 2007 5:30 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Monitoring JAWS adoption trends for
testing/support


Thank you very much Alastair, Lonie, and Norman for your responses.

Alastair: We do in fact use a layered approach to our Dev/Testing by
having a Developer run Bobby against the code (1st layer) to catch most
of
the low hanging fruit, and then some, looking to bake accessibility into

the product before it even gets to QA. The JAWS testing my team does is

primarily to test the user experience, and secondarily accessibility, as
a
check and balance for the work Dev does.

Norman: You made a comment that you stay behind a version or 2 on
purpose
because if it works in an older version, it must work in a newer one. I

actually thought the same thing, but what is interesting (and quite
ironic) is that I had a production trouble ticket come to me today with
a
user complaining about issues using JAWS 7.1. Apparently our App
Support
person told the user to just downgrade to v6.1, which is what we
currently
test and support for our product, and of course the user refused. I am
going to have to dig into the specifics of the issue... maybe it's just
an
isolated case and exception to the rule?

I understand what everyone is saying about using and testing different
technologies, but the truth is when you have extremely limited
resources,
and can only support 1 version, you are forced to go with the majority
(if
anyone can ever figure that out).

Thanks

Costa Avradopoulos
Manager, Software Quality
Ecommerce - Product Development
= EMAIL ADDRESS REMOVED =

CheckFree. The business of money uncomplicatedSM.
http://www.checkfree.com