[nfbcs] Should JAWS be used for web accessibility testing (was Re: Opinions?)

Sat Feb 25 13:51:19 UTC 2012

It's my opinion that, so much as possible, making things work well for the
casual user, like my sister-in-law, will also make them work well for the
more savvy user.  I know some of the tricks to make stuff work, but, if it
gets complicated, I really have better things to do.
I guess I've gotten lazy in my old age.  I want to do what I want to do
without a lot of extra fooling around.
Tracy

> I agree with much of what Mike says.  But he missed one very important
> thing.  By having all evaluation done by IT types he misses the true wants
> and needs of the average computer user.  What works well for me an IT
> professional.  However my sister who just wants to have the stupid thing
> work for her tasks, what is working can be defined differently.
>
> Standards need to be agreed upon and set.  Testing needs to occur.  This
> testing should be both at an IT professional level and finally with
> end-users testing the product.  That is not always going to happen.  In
> the
> best situations it finds and solves a lot of problems.
>
>
>
> Thanks, William
>
>
> -----Original Message-----
> From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On Behalf
> Of Mike Jolls
> Sent: Sunday, February 19, 2012 5:55 PM
> To: 'NFB in Computer Science Mailing List'
> Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing
> (was
> Re: Opinions?)
>
> 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
>
>
> _______________________________________________
> 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/william.ritchhart%40sbcgl
> obal.net
>
>
> _______________________________________________
> 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/carcione%40access.net
>