Re: VoiceOver [Was Re: screen-reader versus self-voicing app]

Hi Chris and all,

----- Original Message ----- 
From: "Chris Blouch" <cblouch@aol.com>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: "T.V Raman" <raman@google.com>; <lisa@ubaccess.com>; 
<unagi69@concentric.net>; <chaals@opera.com>; <st@isoc.nl>; 
<public-html@w3.org>; <wai-xtech@w3.org>
Sent: Friday, September 14, 2007 10:50 AM
Subject: VoiceOver [Was Re: screen-reader versus self-voicing app]


Since your comments are a bit wide reaching in scope and touch on
platform specifics, I'm curious as to what folks think of Apple's
VoiceOver approach, especially the new version coming out in Leopard. It
had a few aspects I think merits consideration:

Being built into the OS should give it more visibility into what's going on 
in the UI. It also means that VO has a huge installed base so any
machine running OSX 10.4 (released April 2005) has a screen reader "for
free". This enables some measure of self-service because there is no
installation/setup. Does this model of building it into the OS rather
than engaging 3rd party vendors hurt or help? Yes, I realize that if
they didn't roll their own there might not be any screen reader for the Mac.

It helps and then it doesn't.  The shortcoming of not using it on a daily 
basis the way someone not seeing the screen or using a mouse would use it 
hurts.  The thing we really have going for us here is the api where things 
can fairly easily be built accessably from the ground up so I am told.

Apple is pushing the idea that stuff going on in the AT needs to have a
visual representation for collaboration. Often times Jaws is reading
stuff off the screen or focus is being moved around with no visual cue
to help a coworker who is trying to follow. Apple has gone so far as to
visually display the braille that goes to an external device. Is this
really valuable or just a gimmick?

It is valuable in thatinstruction and implementation on the development side 
can be enhanced.  If you don't have a braille display, I guess you loose 
that though?

VoiceOver takes a very different approach of trying to geographically
navigate the visual display, jumping between major sections and then
diving into a particular section. Those who come from Jaws or WindowEyes
usually struggle with this at first. It has some advantages in that the
content navigation in VO mirrors navigation with a mouse. Is this really
a better way or will it break down in some situations?
Tradeoffs are in evidence after my over two years of using it on a daily 
basis but I'd say the gains are worth the losses.  I have a much better 
understanding of how things work visually on a computer now than I had 
before and yes, I still use jaws and keep it up to date so I know what I'm 
not missing.

Very nice new voice which Apple claims can hit  more than 750 WPM. They
have breath support and other hints that make it sounds pretty
realistic. Anyone actually try this out to see if it is intelligible at
higher speech rates?

If I did and told you, according to apple, I'd have to shoot you.

CB

Gregory J. Rosmaita wrote:
> aloha, raman!
>
> yes, i should have stated my assumptions up-front, but in a world
> where the windows platform enjoys such market dominance, i thought it
> safe to assume that -- for an average user -- the system upon which
> she or he has to work is most likely a windows box, or at least, a GUI
> interface, but then again, i know how to parse assume into its
> constituent parts, and i should have stated them up front...
>
> i was referring to self-voicing applications in the windows environment,
> rather than any and all self-voicing applications -- emacspeak doesn't
> present the perceptual black holes that a windows-based self-voicing
> application can cause by being unable to interpret the underlying OS
> interface, when invoked from within the self-voicing application as it
> enables an aural user interface which contains, or can be extended to
> contain, whatever one needs in order to work with documents, create
> documents, and render documents...  on the topic of aural user
> interfaces, the book of the same title, by raman, is HIGHLY recommended
> reading for all members of this (or any other) WG...
>
> once used, the power and advantages of emacspeak are undeniable,
> compared to anything else out there (although i've heard that the
> latest releases of Orca have astounded those fortunate enough to
> have access to them), but, for the average user who just wants to
> earn a paycheck or email friends and relations, the learning curve
> is simply too steep to be a realistic alternative for a very significant
> proportion of the targetted user group...
>
> i pine for the days when i used emacspeak almost exclusively, but when i
> became heavily involved in the visually impaired computer users' group of
> new york city and in the authoring tool and user agent accessibility
> guidelines working groups at the w3c, i quickly realized that if i was to
> provide meaningful assistance to group members and useable advice to tool
> makers -- most of whom worked in "locked-down" windows environments,
> and had no choice in the matter -- i, too, would have to work extensively
> in that environment, rather than that which i prefered and which launched
> my webmastering career...  it is easy to switch from one box to another,
> if you have the hardware and the available mental-RAM to keep vastly
> different operating procedures in one's head, but that does not endow one
> with a realistic appreciation of how poor and how slow development of
> assistive technology has been on the windows platform...
>
> these were the days when the only option was to either keep switching
> between machines or attempting a dual-boot setup, not today's world of
> virtual machines which actually can run not only windows software, but
> windows assisstive technology reliably...  when i established a wide
> area network and email services for american foundation for the blind, i
> did so using emacspeak, but when i had to provide assistance to sighted
> and blind colleagues alike, it was invariably in the windows
> environment...  i have always chaffed at the limits of a GUI interface,
> as it is merely a pre-determined and limiting set of options from which
> one has to choose, and personally vastly prefer working from the command
> line, but for me that was a luxury, when it came to providing meaningful
> assistance to persons in work situations where i was contacted to either
> specify a workstation for a blind user or to assist blind users using
> windows-based products...  i quickly came to realize the disconnect that
> threatened to seperate me from the vast majority of those with whom i
> came into contact, unless i underwent the frustrations and encountered
> the peculiarities of windows based screen readers and their interaction
> with "mainstream" applications, i wouldn't be on the same plane as the
> users i was tasked with assisting -- so i stopped turning to a command
> line interface, using emacspeak do get work done, quickly and
> efficiently, to living with the devil that sits so heavily on the
> shoulders of most blind users -- the after-the-fact bolting-on of
> accessibility patches, bridges, and programs to provide a sheen of
> accessibility...  it also helped me with dealing with the major screen
> reader vendors with which most blind individuals in the united states,
> as i intimately knew the troubles with each screen readers, and could
> bring enough technical expertise to the problem statement so that the
> AT developer needed only to effect a change based upon an analysis of
> the administrative and technical/diagnostic information i provided,
> in order to help isolate bugs and point developers in specific,
> targetted directions...  otherwise, i would have been no different than
> the sighted person who uses a screen-reader to test its fucntionality
> and provide "expert assistance" to those dependent upon a screen-reader,
> without turning off the monitor, and uplugging the mouse...
>
> i suppose the impasse is similar to that ennunciated by those who ask:
> "why would a blind person want to watch TV?" -- obviously, to participate
> in the wider shared cultural experience with which TV is capable of
> generating...
>
> not all self-voicing applications are limited, but those to which most
> individuals have access which can be run in a "locked-down" user
> environement are supplemental to a base screen-reader, not an
> alternative...
>
> gregory.
> --------------------------------------------------------
> APHORISM, n.  Predigested wisdom.
>                -- Ambrose Bierce, The Devil's Dictionary
> --------------------------------------------------------
> Gregory J. Rosmaita, oedipus@hicom.net
> Camera Obscura: http://www.hicom.net/~oedipus/index.html
> --------------------------------------------------------
> ---------- Original Message -----------
> From: "T.V Raman" <raman@google.com>
> To: lisa@ubaccess.com
> Cc: unagi69@concentric.net, chaals@opera.com, st@isoc.nl, public-
> html@w3.org, wai-xtech@w3.org
> Sent: Tue, 11 Sep 2007 11:22:25 -0700
> Subject: RE: screen-reader versus self-voicing app (was: Re: Screen-
> reader  behaviour)
>
>
>> +Gregory's summary though written in a nice logical progression
>> starts with a couple of strong assumptions which leads to the
>> conclusions he arrives at.
>>
>> I've used a self-voicing app -- Emacspeak -- for the last 12
>> years, and everyone here who knows me knows that I am more than a
>> casual computer user.
>>
>> So Gregory -- in future, when you write something like this,
>> clearly document your opening assumption.
>>
>> In this particular case, your opening assumptions were:
>>
>> A) User is victim to a locked-down "user environment"
>> B) You confused "operating system" with "user environment".
>>
>> In the Linux / Emacspeak case, neither (A) and (B)  are true,
>> which consequently debunks most of what you wrote ---
>>
>
>
>

Received on Friday, 14 September 2007 15:08:52 UTC