A question that comes up from time to time to which I have made indirect reference in my postings about SMA contracts and, to some extent, in other items, asks whether or not their exists a silent, unwritten contract between AT vendors and their customers. Recently, I received an email from a boss at one of the screen reader companies (not FS) that made a point of stating that quality always topped the feature list for each of their releases. Having not done a solid side by side comparison of JAWS, Hal, Window-Eyes and Freedom Box System Access, I can’t speak directly to which, if any, demonstrates more stability than the others. I can, however, comment on the promise or lack thereof that a screen reader will serve as a partner to its user and grow along with the user’s needs as well as remain usable in programs that the user has grown to count on.
This also presents an issue about which I can understand both sides of the argument.
Today is February 22, 2006. Throughout the world, some screen reader users will, today, start up their computers and hear the Windows ’95 sound play and hear JAWS 3.2 or the version of their favorite screen reader start. These people remain content with their older systems and don’t feel a strong urge to upgrade. When they do, however, the cost can grow far beyond proportion to that which their sighted counterparts who lagged behind the technology curve for a while. To wit: they need to buy a new PC and as they don’t feel the need to buy a supercomputer, they plunk down the $799 for a pretty vanilla Dell system. As the copy of Office ’95 still works well for them, they didn’t think they needed to upgrade but, as they were paying $900 to their screen reader vendor, to buy a new copy (11 years of upgrades would have cost more than an entirely new copy) they learn that the screen reader no longer supports any version of Office prior to 2000 so they pay another $350 to Dell to get Office 2003 with their computer. They have now spent over $2000 to get a system for which their sighted counterparts would have paid much less.
We explored the question of where the responsibility for accessibility lies in an earlier posting. There, I couldn’t find a definitive answer and, for the time being at least, I will work under the assumption that the status quo will remain intact and that we blinks must buy our AT from AT vendors and our operating systems and applications elsewhere. Possibly, this solution is best as the AT companies focus entirely on making products for, in this case, blind people and, therefore, are probably more motivated to serve the blind users than big mega corporations where our needs may get lost in the proverbial sauce. [Look to the earlier posting to see other arguments on this issue.]
The economics of developing a screen reader force the companies that do so to make very difficult decisions. Every one of the screen reader vendors wants to provide the best and most useful solution to their users. Unfortunately, a lack of both time and money, even among the biggest in this industry, can get in the way. Thus, people with the best intentions in mind need to decide that their AT will no longer support an operating system or version of Office or other program that the manufacturer has stopped selling years earlier. They know that some users will, as a result of their decision, have to buy new software and, in some cases, new computers to run the newer operating systems and software packages. These decisions do not come easily to those forced to make them as they know the economic hardship that they can cause.
At the same time, the features supported in some applications may stop working from one release to another. Thus, if I buy the latest operating system and use versions of software recommended by my AT vendor, I may not be able to use the same features I had relied upon to do my job with earlier versions of my screen reader. This also presents a complex problem as when an application developer changes their software it will “look” different to a screen reader and might cause some confusion. As users we can report these problems and the AT vendors will make a best effort to remedy them – meanwhile, we need to find a work around to get our jobs done or our boss will get angry.
Is there an unspoken contract between a screen reader vendor and its clients that said vendor will continue to support the applications its customers need to do their jobs? I really want to say “yes” to answer this question but I find myself torn between my utopian vision of a world where screen reader vendors have all of the resources they would need to ensure feature stability from one release to another and the reality of the economics of even trying to test all of the possible cases that could possibly fail in a new release.
Let’s look at this problem using some numbers: We’ll start with JAWS (I don’t know the other screen readers as well to make a solid analysis about them) and its 3000 or so different configuration settings, each of which can affect the behavior of another, intentionally or, in the case of bugs, not. Then we take the number of Windows applications that are listed in the JAWS Popular Applications section of the help file (50 or more last I looked) and the number of Windows versions JAWS supports and their service packs (six or seven at least), the handful of different object models, MSAA, Java Accessibility API and anything else an application can throw at a screen reader to present it with information. Now, add all of the features of all of these applications and operating systems, all of the different device drivers that might affect audio or video on a computer and then factor in all of the different little weirdnesses that every PC manufacturer seems to insist on pre-installing on new products. Now, multiply all of those numbers by each other and you are left with the test matrix that a screen reader must pass to claim complete code coverage. Once, a number of years ago, I actually put estimates in for all of these different numbers and, using Excel, calculated that there were hundreds of trillions of different permutations. If one calculates that each test would take a single second, it would be a century before all of these variables could be tested.
Such stands the paradox, test the code completely at enormous expense or test as much as an AT vendor can afford and use hundreds of beta testers to get the software onto as many permutations as possible and then hope and pray that enough samples get tested to ensure that the screen reader has as few defects as can be found before a release. From experience, I can say that shipping a new version of a screen reader was toasted more often with Alka-Seltzer and Tums than with champagne. This process is complex and causes grey hair on the heads of AT managers.
We’re still left with the quandary: how can screen readers serve the enormous matrix of requirements provided by the panoply of different users without bankrupting themselves in the process. Once again, I have no answer. I think the next generation of accessibility API layers will make more accessibility “automatic” which should solve some of the problems but would require that everyone upgrade to the new OS and buy all new applications all at once to take advantage of the newly improved accessibility – an unlikely event given the enormous cost that solution would present. Screen reader vendors could expand their beta teams but getting a larger set of bugs would only mean that they would have to find more high priced software engineers to fix the bugs which might also point to the poor house.
So, what can be done?
Regular readers will undoubtedly have noticed that I criticize AT and OS vendors quite a lot but I also applaud their successes. The class of software vendors that I feel eat for free at the trough of the smaller AT vendors is, of course, those that develop the applications. Those that need a VPAT do as little as they can to get an AT company to claim compatibility and those that do not (Intuit for instance) will only help if they find some force to drive them toward accessibility. If AT companies and OS vendors can work together to push the application developers to do a lot of this testing the problem can be distributed more evenly and quality of screen readers will improve.
I know that I return to cooperation and communication as a theme pretty often but it seems to be the only route to bring screen reader authors to a point where they can work on real screen reader features rather than working around accessibility problems in the mainstream applications. I can think of hundreds of innovative features that can make screen readers more efficient but cannot dream up a business model that will drive the vendors, given the current climate of always trying to catch up to the next release of an application or OS, to take the leap into the future.
