[nfbcs] Should JAWS be used for webaccessibility testing(was Re: Opinions?)
Mike Freeman
k7uij at panix.com
Mon Feb 20 19:02:54 UTC 2012
John:
You may well be right. However, I just don't see such universal interfaces
becoming widespread; the only people truly enthusiastic about every device
under Heaven talking to each other are geeks; I could be wrong.
Love your quiet satire about the future arguments about accessible devices.
Mike
-----Original Message-----
From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On Behalf
Of John Heim
Sent: Monday, February 20, 2012 9:09 AM
To: NFB in Computer Science Mailing List
Subject: Re: [nfbcs] Should JAWS be used for webaccessibility testing(was
Re: Opinions?)
Right, but the URC standard attempts to do away with the problem of web
developers coming up with new ways to mess up screen readers by specifying a
standard protocol for accessibility. So basically, the problem with flash is
that adobe never paid any attention to accessibility when developing it. Its
hard to put the hooks in afterward, right? So if the URC standard would
catch on, theoretically, that wouldn't happen. I'm not sure this is what
Mike was proposing originally but I think its pretty close.
I've talked to Gregg Venderheiden of the Trace Center at the University of
Wisconsin about this. The Trace Center and Gregg himself were big parts of
the development of the web access standards. He's also into the National
Public Inclusive Infrastructure and Global Public Inclusive Infrastructure
concepts that kind of grew out of the URC idea.
You may think all this is nothing but a pipe dream but I don't think its
that unrealistic. The reason is that manufacturers are going to be looking
for standard ways to make their products accessible and URC spreads the
burden around. A microwave manufacturer wouldn't have to build a talking
microwave oven. They just have to make an interface that you could connect
your laptop to. You buy a printer these days and they all come with a web
setup interface, right? Why not a microwave oven? Amd why not kill two
birds with one stone and have your web interface follow the URC standards?
I don't thinnk its at all unrealistic to think that in 5 years, Freedom
Scientific will be selling something called the URC Mate (I just made that
up) to allow you to update your facebook page, set your thermostat, and heat
some water for your instant coffee. Of course, it will cost $7,000 and have
a 128Mhz CPU and 32Mb of RAM. And we'll all be arguing whether its worth it
vs the $1.99 IPhone app that does almost the same thing.
PS: I'm joking, of course. I have a Pac Mate classic and I love (and hate
it). I wouldn't have paid $6,00 for it new but at $1500 used, I think it was
a good deal. Anyway, lets not get into a Pac Mate war here.
----- Original Message -----
From: "Mike Freeman" <k7uij at panix.com>
To: "'NFB in Computer Science Mailing List'" <nfbcs at nfbnet.org>
Sent: Monday, February 20, 2012 9:01 AM
Subject: Re: [nfbcs] Should JAWS be used for webaccessibility testing(was
Re: Opinions?)
> John:
>
> It happens to all of us. When I was in college, I invented a
> variable-gear-ratio transmission but obviously never did anything about it
> because I was an impoverished student who didn't have much of an interface
> with the corporate world (which was the "enemy", in this case -- it was
> the
> 1960's). A few years later, I read that a company in the Netherlands had
> invented just such an animal and although the details were different, the
> concept, in broad outline, was pretty-much the same as mine. One fortune
> down the drain.
>
> But back to the issue at hand. The problems I see with Mike's suggestion
> below are that (1) without some rather strong legal sanctions, there's
> nothing to force web developers to use any standard API so there's no
> guarantee that screen-readers will have the information they need -- look
> at
> Java -- and (2) short of constraining innovation, there's no way to truly
> anticipate what code web developers are going to think up and therefore
> there's no way short of constraining innovation of designing a standard
> API.
> I alluded to this in an earlier post.
>
> NFB's R&D committee is beginning to discuss this issue and the only
> alternative that might untie the Gordian knot we find ourselves in that we
> can think of is a screen-reader based upon *very* intelligent OCR. But I
> wonder if even *this* makes sense in that what IMO this *really* means is
> that we're looking for Mr. Data from STNG.
>
> Mike
>
>
> -----Original Message-----
> From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On Behalf
> Of John Heim
> Sent: Monday, February 20, 2012 6:07 AM
> To: NFB in Computer Science Mailing List
> Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing(was
> Re: Opinions?)
>
> What you are refering to is called a "Universal Remote Console". See
> http://trace.wisc.edu/urc/
>
> IMO, you should be congratulated for some pretty clever thinking even if
> you
>
> weren't exactly the first to come up with the idea. When I was in
> highschool, I invented an engine for inter-stellar travel. My idea was
> that
> you scoop up hydrogen as you fly through space and use it to power your
> fusion reactor. My highschool physics teacher said, "You know, John,
> that's
> a great idea. I even have an idea of what you should call it, the ion
> ramjet." I was like, "Yeah, exactly!" He said, "You're not getting it, its
> already been invented and that's what its called."
>
> Even so...
>
> ----- Original Message -----
>
> From: "Mike Jolls" <majolls at cox.net>
> To: "'NFB in Computer Science Mailing List'" <nfbcs at nfbnet.org>
> Sent: Monday, February 20, 2012 4:30 AM
> Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing(was
> Re: Opinions?)
>
>
>>I want to correct myself on a prior post. I mentioned a "standard set of
>> functions" that screen readers should support. What I meant to say ...
>> at
>> least in the context of browsers for the web ... is that this board of
>> "savvy blind users" who develop the standard set of functions, would
>> develop
>> the interface that would be provided by and implemented by browser
>> developers and would be used by screen reader software to access data in
>> the
>> browser.
>>
>> In other words, consider the following:
>> 1. Screen reader calls the API and asks for next piece of data
>> 2. API calls the browser and asks for next piece of data
>> 3. Browser delivers the data back to API
>> 4. API delivers the data back to screen reader
>>
>> Thus, this API would add a layer of abstraction to the problem of
>> obtaining
>> data from the browser environment such that a screen reader ... if we
>> limit
>> the discussion to the context of reading web browser data ... wouldn't
>> have
>> to worry about how the data was organized in the browser. The browser
>> would
>> have to worry about that. This would put this headache on the browser
>> developers and the screen reader would no longer have to code around data
>> organization problems. It wouldn't matter if some piece of data wasn't
>> formatted correctly. The API would provide a function such as ...
>> "GetNextElement()". When called, it would be the browser's
>> responsibility
>> to deal with the organization of the data, thus relieving the screen
>> reader
>> from having to write a bunch of very detailed and exception oriented code
>> to
>> handle problems such as ... "what if the <P> tag is out of place?"... or
>> ... "now we have to handle the <H1> tag appearing in the wrong place if
>> it's
>> the 7th Tuesday of the month and the year is 1215 AD". You can see that
>> having to code such exception-based code could be done by the screen
>> reader
>> ... but why? It just makes the screen reader bloated and hard to
>> maintain.
>> And there would ALWAYS be another exception.
>>
>> If the API was defined completely, it wouldn't matter what the browser
>> did
>> internally. The screen reader wouldn't have to deal with problems
>> created
>> by the organization of the data. That would be the browsers problem.
>>
>> And here's something else. If a federal law mandated that all browsers
>> developed must implement this interface, then it wouldn't matter what
>> company developed the browser. The screen readers would always have a
>> supported interface that would work for them.
>>
>> Now certainly new technology would come out, and the API would have to be
>> updated eventually, and code would have to be added to screen readers
>> once
>> it was determined that a new technology really needed to be supported.
>> However, with a good API, the screen reader developers ... again if we
>> limit
>> the discussion for web browsing ... would likely have a lot less
>> headaches
>> to deal with.
>>
>> Thoughts?
>>
>> -----Original Message-----
>> From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On
>> Behalf
>> Of Nicole B. Torcolini at Home
>> Sent: Monday, February 20, 2012 12:21 AM
>> To: NFB in Computer Science Mailing List
>> Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing
>> (was
>> Re: Opinions?)
>>
>> Thanks for pointing this out. We often get carried away and forget
>> certain
>> important points.
>>
>> ----- Original Message -----
>> From: "David Tseng" <davidct1209 at gmail.com>
>> To: "NFB in Computer Science Mailing List" <nfbcs at nfbnet.org>
>> Sent: Sunday, February 19, 2012 9:52 PM
>> Subject: Re: [nfbcs] Should JAWS be used for web accessibility testing
>> (was
>> Re: Opinions?)
>>
>>
>>> Hi guys,
>>>
>>> Lots of thoughtful replies already to this thread.
>>>
>>> I whole-heartedly agree that companies should test with as many AT's
>>> (including speech recognition, magnifiers in addition to screen
>>> readers). However, when it comes to the practical day-to-day
>>> implementation of such a policy, it's fairly clear, at least on a
>>> technical level, that this type of user-centric testing goes almost no
>>> where without an accessibility expert working on the inside.
>>>
>>> It just happens that most web developers don't speak accessibility.
>>> The actual process of fixing many of the issues confronted by screen
>>> reader users winds up traveling quite a convoluted path. On one end of
>>> the spectrum, we've got web developers who live in the land of HTML,
>>> CSS, javascript, js toolkits, web standards, etc. On the other end,
>>> there are legacy (and not so legacy) screen readers that use in many
>>> cases closed-source, proprietary, platform specific technologies and
>>> techniques to read the screen. In the middle, you have again
>>> proprietary (at least on Windows) accessibility infrastructures at the
>>> operating system level. On top of this, you have potentially if we're
>>> singling out web, various browsers that vary in their support of the
>>> latest and greatest standards whether it be HTML5, or platform
>>> specific API's like IA2, UIA, etc.
>>>
>>> Tell a developer that "Jaws isn't reading a particular table's
>>> contents correctly or Jaws isn't reading a form field" means that
>>> someone has to translate down to apply x attribute to y control as the
>>> "proper" way to inform the control of it's label.
>>>
>>> That's just a *very* simple example. In contrast, there are some
>>> extremely fundamental drawbacks to the way Jaws (and others) control
>>> focus that makes it a challenge at best and impossible at worst to
>>> deliver modern web apps to screen readers of a specific class.
>>>
>>> Also, to point out somewhat of an assumption made on this thread, any
>>> of the parties listed above can prove to be the weakest link. Some
>>> screen reader issues do stem from bugs in the screen reader. Likewise,
>>> there have been more than a few bugs in MSAA itself, the browsers, and
>>> of course, the markup/script from the content author.
>>>
>>> At the end of the day, automated tools provide a great front-line and
>>> a clear, explicit path to resolving a bug (whether it be access
>>> related or not). Testing with screen readers leads to mixed results,
>>> but can be useful if the organization in question has the resources to
>>> investigate and has a good *technical* contact to ask when ambiguity
>>> arises.
>>>
>>> Accessibility testing falls short in many cases because providing the
>>> "what" is only half the story, if that; presenting the "why" and "how"
>>> (to fix) a particular issue on a developer level proves invaluable.
>>>
>>>
>>> On 2/19/12, Mike Jolls <majolls at cox.net> wrote:
>>>> I hear you when you speak of how the coded material is interpreted.
>>>> I probably don't need to go much further than to use HTML as an example
>> ...
>>>> you can code it so it works, but the coding ... even though it works
>>>> ...
>>>> doesn't follow the coding rules. As a result, a screen reader would
>>>> get confused if it was expecting a strict following of the rules (at
>>>> least with respect to HTML) 100% of the time. And another comment
>>>> about the rapidity of changing technology makes it difficult to for
>>>> screen reader developers to keep up. Yes, I recognize all of that.
>>>> Being a developer myself, I can appreciate those problems.
>>>>
>>>> I'm going to go out on a limb here .. and maybe I need to get my
>>>> skills updated a bit ... but it's too bad that a technology like XML
>>>> couldn't be followed when sending information to the browser ... rather
>> than HTML.
>>>> XML
>>>> ... if paired with a well defined DTD would require that the XML data
>>>> is correct and it could reduce problems for screen readers trying to
>>>> interpret improperly formatted content. Perhaps if the browser could
>>>> receive the data in XML instead of HTML you'd stand a better chance
>>>> of preventing the example I'm citing above. Of course as I implied
>>>> in the previous paragraph, HTML is not the only technology where
>>>> problems could occur. Many new technologies are developed and the
>>>> screen reader companies have to keep up with those technologies.
>>>> Since there is such a thing as lag, I suppose the screen reader
>>>> companies will always be behind the proverbial eight-ball. Of course
>>>> in the software business where I work, we call that job security.
>>>> But that doesn't make it easy on blind individuals that depend on
>>>> using screen readers for their delivery system.
>>>>
>>>> Just a few 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 5:45 PM
>>>> To: 'NFB in Computer Science Mailing List'
>>>> Subject: Re: [nfbcs] Should JAWS be used for web accessibility
>>>> testing (was
>>>> Re: Opinions?)
>>>>
>>>> I agree with you, Doug. Moreover, what we're dealing with here is not
>>>> how something looks on the screen (which can be coded in a bazillion
>>>> different
>>>> ways) but how that coded material is interpreted by the
>>>> screen-reader; these are two different things.
>>>>
>>>> As I say, I think the only cogent solutions are to mandate a rigorous
>>>> set of tests with the several screen-readers or to restrict how
>>>> content can be coded for interpretation by said screen-readers so
>>>> they have a prayer of knowing how material will be presented to them
>>>> for interpretation by the blind user.
>>>>
>>>> Mike
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: nfbcs-bounces at nfbnet.org [mailto:nfbcs-bounces at nfbnet.org] On
>>>> Behalf Of Doug Lee
>>>> Sent: Sunday, February 19, 2012 3:09 PM
>>>> To: NFB in Computer Science Mailing List
>>>> Subject: Re: [nfbcs] Should JAWS be used for web accessibility
>>>> testing (was
>>>> Re: Opinions?)
>>>>
>>>> Problem is, I don't think this is so much about what features a
>>>> screen reader should have. It's more about how screen readers
>>>> implement those features, and how the differences among these
>>>> implementations cause different behaviors depending on how developers
>>>> developed their software and web sites. The API idea is good, and
>>>> it's been tried, in the form of things like MSAA, Java Access Bridge,
>>>> UIA, etc. But so far at least, the attempts on standardization of
>>>> methods for screen readers to use have not resulted in complete
>>>> uniformity among screen readers as to how well their features work in
>>>> all situations.
>>>>
>>>> On Sun, Feb 19, 2012 at 04:54:40PM -0600, Mike Jolls wrote:
>>>> 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-a
>>>> ccessib
>>>>> 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.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/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/dgl%40dlee.org
>>>>
>>>> --
>>>> Doug Lee dgl at dlee.org
>>>> http://www.dlee.org
>>>> SSB BART Group doug.lee at ssbbartgroup.com
>>>> http://www.ssbbartgroup.com
>>>> "The most exhausting thing in life is being insincere."
>>>> - Anne Morrow Lindbergh {American Author}
>>>>
>>>> _______________________________________________
>>>> 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/davidct1209%40gmai
>>>> l.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/ntorcolini%40waveca
>>> ble.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/jheim%40math.wisc.edu
>>
>>
>
>
> _______________________________________________
> 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/jheim%40math.wisc.edu
>
>
_______________________________________________
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
More information about the NFBCS
mailing list