[nfbcs] Window-Eyes and terminal emulation

[Doug Lee]

I have used, and scripted for, Attachmate Extra, Reflection, and
probably TN3270, all under JAWS.  I have also experimented somewhat
extensively with Window-Eyes in console environments, though not
specifically in terminal emulators.

I would first say that how much scripting is required depends greatly
on what you want done.  Just getting automatic announcements of screen
changes without such things as constantly spoken session time updates
is usually not that complicated.  Making a screen reader correctly
identify field names is more involved, and doing so for tabular data,
where fields are labeled by column headings, is much more complex.
There are also the issues of forms with page numbers, fields with
automatic help text, announcement of error text when it appears even
if you don't want all screen changes announced ... so as you can see,
the complexity depends quite a bit on your specific needs and
interests.

Exactly how the job is done will also depend on the application/environment
you're using.  The terminal emulator itself doesn't decide where
error messages and form page numbers go, for example; that's up to
the application you're accessing remotely.  (I in fact recently
scripted two different terminal emulators to work with the same
system, and I wrote one set of scripts that adjusts itself to
whichever terminal emulator is being used.)

As for the JAWS-versus-Window-Eyes question:  Both now have powerful
scripting languages, with the JAWS language being more procedural and
the Window-Eyes language more object-oriented.  For a terminal
application though, I assert that the biggest issue that will
determine which screen reader is best equipped will not be the
scripting language but rather the screen reader's ability to detect,
and provide appropriate script events for, screen changes.  In a
terminal environment, most of the complexities of window hierarchy,
MSAA trees, etc. are not applicable since most of the activity of
interest is in a single window, usually without its own direct MSAA
support.  It's mostly down to so-called screen-scraping and event
processing--and the number of possible events is pretty small too.

All that said, my experience indicates that JAWS is currently better
than Window-Eyes at handling screen change events in Windows console
applications, but this observation may not carry over to terminal
emulators since they are not actually "console applications" but are
Windows apps with console-like windows within them.

If you want to compare screen readers quickly on how they handle your
situation, I recommend that you load each screen reader, one at a time
of course, and try these things to see how well they respond.  Do
these with the screen reader set to announce all screen changes.  For
these tests, do your best to ignore any extra announcements of time,
session length, changes in cursor row/column numbers, etc.; these can
be eliminated with scripting.

1.  Run through some commands in your remote application that scroll
results onto the screen without clearing older text, much like a DOS
command window would do in Windows.  See how well the screen reader
manages to announce just what is added, and all of what was just
added, without missing new text or repeating old.

2.  Try that again but with a clear screen first, so there is no
scrolling, only added text.  I don't see this problem so much in
Windows, but it is possible for a screen reader to miss new text when
the rest of the screen does not move.

3.  Try a few things that update various parts of a screen, such as in
a full-screen form, and see again if the screen reader catches the new
text without missing or doubling anything.

My prediction is this:  If your screen reader of choice has a lot of
trouble with the above tests, and another one doesn't have so much
trouble, you're going to have more difficulty scripting yours than the
other one to do what you want, regardless of all other factors.


On Thu, Jan 29, 2009 at 11:00:49AM -0500, Tracy Carcione wrote:
Thanks Curtis.
To make JFW work well with 3270 emulation, I need some fairly complicated
scripts.  Does Window-Eyes also require scripts, or does it work
automagically?  Or does it depend on the emulation software being used,
whether it works well or not?
I know many people use Extra, but my shop does not.  I think they're using
Reflections, but I am using TN3270.  Not that I'm totally committed to
it--I just want something reliable that works with speech.

Tracy

> Tracy:
>
> With regard to Window-Eyes, it does work well with terminal emulation, and
> GW Micro does not charge any extra for things like remote access or
> putting
> Window-Eyes on something like a Citrix terminal server.  Also, you don't
> have to fork out a large chunk of cash to try the program.  I believe you
> can get in for as little as $39 a month or something like that with no
> commitment.  Check with GW Micro or check out the Website www.gwmicro.com.
>
> NVDA si also worth checking out as is System Access.
>
> Cordially,
>
> Curtis Chong
>
>
>
> _______________________________________________
> nfbcs mailing list
> nfbcs at nfbnet.org
> http://www.nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
> To unsubscribe, change your list options or get your account info for
> nfbcs:
> http://www.nfbnet.org/mailman/options/nfbcs_nfbnet.org/carcione%40access.net
>



_______________________________________________
nfbcs mailing list
nfbcs at nfbnet.org
http://www.nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
To unsubscribe, change your list options or get your account info for nfbcs:
http://www.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
"Is your cucumber bitter? Throw it away. Are there briars in your
path? Turn aside. That is enough. Do not go on to say, `Why were
things of this sort ever brought into the world?'"
--Marcus Aurelius