In the past week or so, I’ve received a number of phone calls from friends who are also experts in the screen reader segment of the AT market. Some calls, from friends who work for GW Micro’s competitors told me about all of the security loopholes that are opened up with the new Window-Eyes scripting facility.
I then read up on the feature and agreed that, indeed, it did have some holes. Last week, I posted a message to the blind programming mailing list which started out by celebrating all of the power that is now available in the Window-Eyes 7 beta and that I was excited to see what the community will make of this major advance in screen reader technology.
I also mentioned that there were some security issues in the feature that users should be aware of. I overemphasized the security issues as the notion held center stage in my thoughts on the matter resulting from the calls I received from friends who work for GW competitors, definitely not an impartial group.
After posting the email to the BP list, I got some emails and phone calls from Window-Eyes aficionados, equally expert in the often nuanced ins and outs of the screen reader biz. This group scolded me for bashing GW and felt that my email to the blind programming list was unfair. After rereading my post, I agree with the Window-Eyes supporters, accept that I overstated the security problems and, with this post, I would like to retract my Chicken Little, “the sky is falling” statements.
The Window-Eyes people also reminded me that one can build some very nasty malware in JAWS scripts, especially if the interface DLL is used. They are correct in this assertion and, once again, I’m eating a bit of crow as my email to the BP list was clearly unbalanced.
I do feel strongly that the new scripting facility in Window-Eyes is one of the coolest and most important steps forward in the screen reading business that we’ve seen in quite a long time. People with the ability to program in a wide variety of languages can make some pretty amazing software using this model and I expect we’ll see an explosion of creativity from the community of users in the recent future.
Virtually every program that exposes a COM interface can now work reasonably well with Window-Eyes and programs like MS Project, dropped from the JAWS radar a number of years back, can be supported by the community and, therefore, more blinks will be able to get promotions into the jobs that require project management tools. There are a ton of programs out there that a Window-Eyes hacker can really make sing in a manner that no screen reader could in the past.
I would like to recommend that as many WE extensions as possible be distributed under GPL or Mozilla or one of the other free software licenses and, of course, include source code. As we learned above, all such scripting facilities can open security holes and, if we have the source code, we can ensure that none of the predatory sorts of software vandalism can be performed by said program. Also, open source and free (as in freedom with a lower case “f”) software provides the community with the ability to control our own future and design our technological destiny rather than keeping it in the hands of sighted CEO types who report to sighted boards of directors who only seem to care about the profit line. GW Micro, Serotek and the guys who make the iCon remain, as far as I can see, the most user centric companies in the biz and also deliver real innovation. Humanware deserves an honorable mention for their recent book reading devices which are truly the bomb.
Finally, I haven’t worked for FS nor held an executive position in any AT company in nearly four years. I work on some very cool projects for some very cool people but just because I was a VP of Software Engineering at the biggest screen reader company around doesn’t make my statements on any of this technology any more valuable than any other so-called expert. Thus, if you read an email or blog post that I’ve written, please remember that I’m just one voice in a crowd and that you should read opposing opinions as, god knows, I’m wrong at least half of the time.
— End
I would like to ask that everyone creating open source scripts for Window-Eyes please visit http://www.gwmicro.com/sc and upload them to that wonderful system built by the folks at GW Micro. Of course, the same advice holds for all who seek scripts for their favorite software. There is a new script added or updated every couple of hours! It is an amazing resource!
I am not a programmer, but I do have one question. Does JAWS not have an API of its own, as well as its homegrown scripting language?
From the excitement generated by the Window-eyes 7.0 release, it would seem that the WE API is more powerful than the JFW one. Is this the case, or are we just getting excited about nothing?
While the JAWS scripting language is a proprietary C-style representation, the scripting provided by Window-Eyes is able to utilize any industry-standard scripting language capable of processing COM objects. Windows Script Hosting support is built into Window-Eyes for JScript and VBScript. I feel that this approach is going to be far more robust than that currently offered by Freedom Scientific. While JAS scripters must learn a special language and API, limiting the availability of talent in this area for scripting inaccessible applications, there is the potential for hundreds (or thousands?) of programmers all over the world who already know JScript or VBScript and object-oriented programming to develop scripts for Window-Eyes.
Forgive me, but I thought the JFW API was open? I’ve seen programs written in everything from C# (EdSharp, FileDir), to mIRC scripts (tIRC, mIRCWithSpeech, SJAMS), to Ruby (TextPal).
And by the API, I am referring to the jfwapi.dll library, not the scripting language.
The jfwapi dll only gives these programs the power to make Jaws speak. You can’t otherwise talk to the screen reader to get information, open dialogs, etc. GW Micro’s approach via COM is in a totally different ball park.
Hey Chris,
If you want to bash GW for something then bash them for actually introducing scripting. As you should now by now, most of the problems that scripting solves are actually design flaws in how screen readers present information to people. A good example of this is keyboard accessibility. When you rework the way that screen readers present information to people you find that a lot of these problems disappear. I’ve now got a research prototype for a screen reader user interface that doesn’t have the problems with keyboard accessibility and attention that the conventional screen readers do. So, I don’t need scripting to solve these problems.
The more I look at it the more I think that scripting is some sort of prehistoric band-aid.
Will
Will,
Window-Eyes scripting is quite powerful! I wonder if your research could be implemented as a set of scripts? Wouldn’t that be ironic?