Re: Article on Screen Reader History (including NVDA)

Luke Davis

On 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 Windows programs.

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-reader. 
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 standardization.

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 general.
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 past.

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.


Join to automatically receive all group messages.