toggle quoted messageShow quoted text
I don't know why you didn't have problems. Did either screen-reader
you mentioned do any analysis of the screen the way ASAP and ASAW
did so that certain parts of the screen would be read
In Vocal-eyes, you had to create a set file to automatically do
something when information appeared on certain parts of the screen
or certain types did.
The following may not have been just how you might have done things,
its been a very long time, but you could have done more or less
I didn't use Vocal-eyes except to learn about it but, for example,
you might have created a set file to do more or less the following
automatically read the address line when an at sign appeared on the
You could have had the subject line read when text changed in the
subject line and you could have had the message body automatically
read when text changed on that part of the screen. You could have
defined the message body window so it didn't include unnecessary
text such as the commands that appeared at the bottom of the screen,
thus not having that information automatically read.
On 7/27/2022 12:42 AM, Luke Davis
Jul 25, Gene wrote:
I remember when, time after time, a new
version of Pine came out and users of shell accounts would have
to alter the Vocal-ize set file for Pine so the
program would work properly.
I suspect that was more a deficiency in the way Vocal-Eyes did
things, although I never used it so can't be sure.
I know however that all through out the 90s, I used pine via a
terminal program, with both the IBM Screen Reader and Tinytalk,
and never had to change anything about the screen reader at all to
keep using it effectively across multiple pine versions, and even
builds for different operating systems.
In general the pine interface (like many of its Ncurses-based
brethren) was one of the most unchanging of any full screen
programs around for the vast majority of its life span. Up to and
including Alpine, its spiritual successor.
And that is not to say anything negative
against Vocal-ize, it is to point out how much accessibility has
advanced and how much Windows screen-readers now
can work with all sorts of programs without having to be
especially caused to work with them.
What I said above not withstanding, I would equate what you
describe with having to modify or upgrade JAWS scripts, or NVDA
add-ons, to maintain compatibility with changing versions of
Some software always requires the screen reader to have a little
help in order to access it, and that help needs to be upgraded
from time to time as the software changes.
Personally I wouldn't make any general judgements about
accessibility now or then based upon that factor, because in truth
it is just as necessary now as it was then, for the subset of
cases where it is necessary, whether you call it a script, a set
file, or an add-on.
I can use program after program with NVDA
or JAWS and those screen-readers aren't scripted or tailored to
work specifically with those programs in any way.
Actually, a lot of times they are. It is just carried internally,
without you having to install something like an add-on or script.
NVDA, for example, carries something like 100 internal modules
dedicated to the support of one specific program each. Not
including the more generalized support that underlies it all.
Sometimes they don't have to do much, but fix one little access
quirk. Other times they have to do a lot more.
Thunderbird, Zoom, One Password, Windows Mail, all the MS Office
applications, Skype, Kindle, iTunes, Windows Explorer, Windows
Calculator, are just a few examples of more popular programs that
NVDA supports with specific dedicated code.
Because despite what I say below, there is still enough
variability in the interfaces that programs use, that screen
readers still have to work around it. It just isn't at as low a
level as it used to be, and the information is often easier for
the screen reader to find without screen scraping these days.
and there is a lot more uniform structure
in Windows programs. Dialogs are generally dialogs, menus are
generally menus, etc. In a lot of programs, I can
work with these structures without any adaptation of the
Screen-readers have become much more capable but also, Windows
and Windows programs are often structurally much more similar
than DOS programs were.
The trend in software as a whole--be it Windows or commandlines
such as shell accounts provide (the commandline side of the *nix
platforms), or the *nix windowing environments--is toward library
Back in the day, everybody rolled their own for everything. Even
in early Windows, there were countless ways to do things such as
displaying text in windows, drawing things to be shown on the
screen, revealing that data (or not) to other programs that might
be running, and so on.
Everybody had their own idea about how best to program around
limited memory and processing power, what corners could be cut,
and how to deal with limited disk space.
Screen readers had to learn to work with, and around, all of that.
As time progressed, and computers and their elements (space,
memory, processors) became both more standardized and cheaper, it
became viable for standard approaches to things such as displaying
windows, graphics, text, and informational presentation in
Programming became more and more abstracted from the immediate
interface with the user, and both in Windows and *nix
environments, standard libraries began doing a lot of the nuts and
bolts hardware interface work. That made it easier for screen
readers, both Windows and the commandline sorts, to work on a
general class of programs, rather than having to be modified to
work with individual programs as was much more the case in the
That trend started on the commandline side a lot sooner, helped
along by open source and the "openness of the basics" ideas it
promoted in the industry.
I suspect it had different driving forces on the Windows side--the
complexity of Windowing environments making it harder for entry
level programmers to get up to speed without standardized
interfaces to plug into, being one of them. It's a lot harder to
keep re-inventing the wheel, when the wheel needs to look and act
like a hundred other wheels running beside it.
And the more complex a system layer becomes, the more security
plays a part in standardizing it: in this case, the security of
what the operating system lets its third party programs access of
its internals in order to get a particular job done.
But this is getting way in the weeds.