[nfbcs] Should JAWS be used for webaccessibility testing(was Re: Opinions?)
David Tseng
davidct1209 at gmail.com
Mon Feb 20 19:33:25 UTC 2012
On 2/20/12, John Heim <jheim at math.wisc.edu> wrote:
> 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.
>
The URC standard reads more like a device to device communication
protocol ala TCP, SATA, etc. Though perfectly feasible to conceive of
a day when a device talks to another via this protocol, we're talking
about the abstractions of processes running on top of a operating
system (for web access) and not of hardware devices. Certainly, this
doesn't preclude people from adopting URC for a specific platform
technology stack, it does require the bending of traditional rules
surrounding inter process communication. I do think that you're
conflating two very separate technologies.
> 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.
>
If the standard specifies how a hardware device talks to a process
running on your machine or to the operating system layer, then
certainly, I have no objection to such a strategy.
I love the idea of a protocol to allow for a separate device to
consume user interface data over the wire as you pointed out in your
microwave/appliance examples. There's definitely lots of value in such
a system. However, I fail to see how this relates to web
accessibility.
- David
On 2/20/12, John Heim <jheim at math.wisc.edu> wrote:
> 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/davidct1209%40gmail.com
>
More information about the NFBCS
mailing list