[nfbcs] Should JAWS be used for web accessibility testing (was Re: Opinions?)
Mike Jolls
majolls at cox.net
Sun Feb 19 22:54:40 UTC 2012
OK, let me put my two cents in here. And I'll hopefully make this brief.
If I'm hearing this right, I'm hearing that one screen reader (say it's
JAWS) is made the standard, and all other players should play by the
features that are incorporated in the chosen standard software package.
I say that's a bunch of hooey.
What needs to happen is a standard set of functions ... arrived at by a
board of computer savvy blind people ... should be agreed upon. Such as...
1. Navigate from frame to frame
2. Navigate from word to word
3. Navigate from paragraph to paragraph
4. There are many more .. these are just examples.
And this group of blind people should be computer educated (i.e. trained
people who understand about computer technology, what type of data is going
to appear on the web)
who understand what needs a blind person has when they want to access
content on the web ... that is if we're only talking about accessing the
web. If we're talking about accessing other things such as FTP servers and
other technology, these people would need to be versed in those technologies
as well.
Now, with a group of people who understand the media to be accessed and what
is possible, they agree to a standard set of functions that EVERY company
that writes screen reader software must support. In fact, perhaps this
savvy group if knowledgeable in computer technology, could come up with an
API (application program interface) that they could design that every
producer of screen readers would have to adhere to. If the set of features
outlined in the API was complete, then any company producing screen reader
technology would have to implement at least those functions, and every
package would have at least the same basic set of functions usable by blind
people that the standards board decided was important and necessary. Each
product by different vendors wouldn't have to implement them the same way
(i.e. CTRL-R might "Read the entire line" for Company A's product, while
CAPS-LOCK-I would do it for Freedom Scientific JAWS) ... but they would have
to implement the agreed upon standard set of functions. This would go for
cheap software, or the cadillac versions. That way, a blind person would be
given choice, based on what he could afford. Heck, if there was a published
API, maybe Microsoft might even get it right and embed a screen reader in
their O/S.
In this way, different companies could produce their own products, there
could be competition, there could be cheaper and more expensive models, and
users would still get what they needed ... plus any additional features the
more expensive packages offer.
So that's what I think needs to be done to solve the issue of which screen
reader to buy. Which one you should buy shouldn't matter if they all
supported the basic "have to have" features.
Thoughts?
-----Original Message-----
From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On Behalf
Of Mike Freeman
Sent: Sunday, February 19, 2012 3:52 PM
To: 'NFB in Computer Science Mailing List'
Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing (was
Re: Opinions?)
Jim:
Thank you for your articulate response. Here's my answer.
With regard to my setting the bar too high for testing, you bet your sweet
posterior I am! In fact, I think that we as a society in general and
companies in particular have become *way* too sloppy both in coding
standards and in the level of perfection we expect from the software and
hardware we use. There are computers using older operating systems where I
work that have been up -- continuously -- for nearly two years. Put *that*
in Windows' pipe and smoke it! And way too many bugs slip through in vendor
software (both Microsoft and otherwise) these days because the testing
wasn't sufficiently vigorous to catch them. And yes, I realize that were the
sort of testing I advocate done, it might slow down web site and software
changes to perhaps two a year! Bravo! That's *exactly* what I think should
happen. If corporations and individuals knew they'd only have two chances a
year to make changes, they might concentrate a bit more on getting things
right the *first* time rather than using the users as beta-testers!
I know you'll object that content changes more often than this on web sites.
You're right. But I see little reason for this -- especially as a good bit
of the change is pure glitz designed to try to attract new viewers etc. Why
not assume people to be literate and intelligent and try to attract them
with well-written *text* content?
But I realize I'm jousting at windmills on this one. Given this, then, what
should we do? I think your suggestion of picking a standard screen-reader
that doesn't depend upon direct sales is impractical at best. I maintain
that eventually *all* screen-readers will have to be maintained based upon
sales; even the purveyors of NVDA are having to admit that they might be
hungry and would like some contributions. If we admit that there's no such
thing as a free lunch and if we admit that changing screen-readers involves
more than a sighted person goes through in changing browsers because his web
experience isn't as good with one as with another, the only alternative I
then see short of my utopian test suite and regime would be to specify
allowed and disallowed web constructs and software constructs and, say,
limiting them to, for example, what one could do with standard windows
controls as implemented in Windows-98. In other words, as I see it, we
either allow innovation and insist upon a rigorous testing regimen or we
specify that no innovation beyond a certain level is allowed with the
penalty for violation being the immediate job termination of a company's CEO
and executive board.
And we know that isn't going to happen either and probably it shouldn't
(although I confess that a good bit of nonsense in today's society would be
solved if people knew their jobs were on the line for foisting it on the
rest of us!).
Mike
-----Original Message-----
From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On Behalf
Of Jim Barbour
Sent: Sunday, February 19, 2012 12:16 PM
To: NFB in Computer Science Mailing List
Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing (was
Re: Opinions?)
Oh, this is very interesting. Thank you Mike for articulating the other
side of this.
I'd like to quote and then respond two items from your message.
First Quote:
"I think the only way to do this right would be to specify that *every* site
should be put through a suite of tests by *human* *beings,* not automated
tools, using the following screen-readers at a minimum: JAWS, Window-eyes,
Hal, SuperNova, System Access, NVDA, Coco (sp) and VoiceOver (both on
i-devices and on the Mac). It's a matter for debate whether or not one
should specify note-takers such as the BrailleSense and BrailleNote family
also to be tested."
Ignoring for the moment the word "every" in your statement above, let's
think about large companies that want to test accessibility, such as Google,
Yahoo, and Facebook.
You're proposing that these companies stage human run usability tests on
*each* new or changed product using 8 to 10 different AT solutions.
As a comparison, none of the companies I mention above would consider doing
this amount of mainstream usability testing against different web browsers.
I believe that this is way to high a bar for us to expect any web site
developer to meet
Instead, we should pick a model screen reader, and begin to insist that it
be used in *all* AT usability testing. That screen reader could then be
given the responsibility of reporting out problems they encounter for which
there is no documented solution. This puts that company in the drivers seat
for finding a solution.
For this to work, we need a screen reader whose development is not financed
by direct sales.
As to the word "every", I don't think you really mean every web site
developer. If I develop a photo sharing site for my family to use, say
www.barboursphotos.com, this probably should not have to pass the
accessibility test.
The question about who should be obliged to pass any accessibility tests is
a sticky one.
And, your second quote
"In fact, I think the article's author is desperately trying to find a way
to lessen work for himself or, put another way, he is hoping he can be lazy
and not do the sort of in-depth testing that is truly required for good
accessibility testing."
So, of course he is. He's trying to minimize the amount of effort needed to
make his web sites accessible. This is reasonable and makes perfect sense
to me. Why wouldn't you expect any developer of any product to increase
their efficiency?
Jim
On Sat, Feb 18, 2012 at 08:49:22PM -0800, Mike Freeman wrote:
> Jim:
>
> I respectfully, but strongly, disagree. Although I argue in another
message
> that there's no good way to include or exclude a particular
> screen-reader from accessibility or usability tests, I also think that
> excluding a particular screen-reader amounts to a value judgment even
> if it is not intended as such. Consider how irked Window-eyes users
> get when everyone tests their sites against JAWS. Why should JAWS
> users put up with the same sort of nonsense?
>
> In fact, I think the article's author is desperately trying to find a
> way
to
> lessen work for himself or, put another way, he is hoping he can be
> lazy
and
> not do the sort of in-depth testing that is truly required for good
> accessibility testing.
>
> I think the only way to do this right would be to specify that *every*
site
> should be put through a suite of tests by *human* *beings,* not
> automated tools, using the following screen-readers at a minimum:
> JAWS, Window-eyes, Hal, SuperNova, System Access, NVDA, Coco (sp) and
> VoiceOver (both on i-devices and on the Mac). It's a matter for debate
> whether or not one should specify note-takers such as the BrailleSense
> and BrailleNote family also to be tested.
>
> The only alternative I can see would be to try to get all
> screen-readers
to
> behave the same way and, my friends, that ain't a-gonna happen! (grin)
>
> Mike Freeman
>
>
> -----Original Message-----
> From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On
> Behalf Of Jim Barbour
> Sent: Saturday, February 18, 2012 8:21 PM
> To: NFB in Computer Science Mailing List
> Cc: NABS-L
> Subject: [nfbcs] Should JAWS be used for web accessibility testing
> (was
Re:
> Opinions?)
>
> I am in 100% agreement with the statement that JAWS should not be used
> for web site testing. However, my reasons differ from the ones
> written in the article.
>
> It is not possible today to design and build accessible websites
> without performing usability tests. Further, there are too many
> access technologies to test with them all. So, the question is which
> AT should be used to test, and therefore drive improvements to, web
> site accessibility? Whichever one gets chosen will have the
> opportunity to informally set standards around how certain types of
> content will be handled.
>
> Given this, I think JAWS is not the right answer. Perhaps NVDA or
> SA to go or some other screen reader I'm not aware of could step in?
>
> Jim
>
> On Sat, Feb 18, 2012 at 07:21:31PM -0800, Nicole B. Torcolini at Home
wrote:
> > When doing some research for a project, I found the following article.
> What do people think?
> >
>
http://clearhelper.wordpress.com/2010/03/16/stop-using-jaws-for-web-accessib
> ility-testing/
> > _______________________________________________
> > nfbcs mailing list
> > nfbcs at nfbnet.org
> > http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> > To unsubscribe, change your list options or get your account info
> > for
> nfbcs:
> > http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/jbar%40barcore.co
> > m
> >
>
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for
nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/k7uij%40panix.com
>
>
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for
nfbcs:
> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/jbar%40barcore.com
>
_______________________________________________
nfbcs mailing list
nfbcs at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
To unsubscribe, change your list options or get your account info for nfbcs:
http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/k7uij%40panix.com
_______________________________________________
nfbcs mailing list
nfbcs at nfbnet.org
http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
To unsubscribe, change your list options or get your account info for nfbcs:
http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/majolls%40cox.net
More information about the NFBCS
mailing list