The GW Micro blog has been discontinued. For instant updates on GW Micro products and events, follow us on Twitter, and like us on Facebook.
Accessibility vs. Usability
by Aaron Smith on Thursday, June 7 2007We’ve been having a rousing discussion on the GW-Info list regarding, well, I don’t really remember what we were talking about at this point. But I was asked to post the following message, and I hate to disappoint. You can find all the 100 plus messages on this topic on the GW-Info archive page. Honestly, as annoying as these back and forths can get, I do think healthy discussions are important, and ultimately, in a twisted kind of way, help shape Window-Eyes development.
Enjoy!
There’s a difference between an application that’s not accessible (i.e. not usable) and one that does not have sets with user windows, cursoring keys, or other bells and whistles (i.e. usable, but not customized). Applications that are not customized should not be on a list of applications that are not accessible. Thems apples and bananas if you ask me.
Someone else, Rick I think, alluded that knowledge of an application and of Window-Eyes is paramount to the "accessibility" of an application -- that’s an argument we’ve had on this list several times, and one we’ll have until the sun burns out. One user might claim the non-automatic reading of changing items on a status bar makes an application inaccessible, whereas another user might set up a hyperactive window around the status bar, and never even contemplate the application’s accessibility. Yet another user might leave the mouse pointer on the status line, and use the read current mouse line hot key whenever they wanted to know what the status line says, again never thinking about whether the application was accessible or not. The more you know about Window-Eyes, and the more you know about the application you’re using, the fewer "accessibility" issues (note the quotes) you’ll have.
Having said that, let it henceforth be known that I am on the scripting bandwagon; I think some very cool things can be done with scripting. My laptop doesn’t have physical volume keys, so I scripted AutoHotkey to increase or decrease the volume when I pressed either the WINDOWS-UP or WINDOWS-DOWN keys respectively. So I know the benefit of scripting.
At the same time, people who don’t know how to use the features of set files (i.e. setting up user windows, modifying cursoring keys, tweaking verbosity and general settings, etc.) are, more than likely not going to have the knowledge to create scripts. So, to them, scripts don’t make an application any more accessible than sets. In addition, the current set file features that Window-Eyes offers are all available through a GUI, meaning that you can do a massive amount of customization using standard controls (dialogs, buttons, check boxes, etc.). For example. setting up a user window requires very little typing, but rather putting the mouse in specific places, and pressing a few hot keys. That’s simple. Setting up a similar function using a script requires knowledge of whatever scripting language might be used, the syntax of that language, the syntax of communicating with the API being used, and knowledge of the feature being scripted. Sure, there’s more flexibility, and more control, but it requires more knowledge. That’s complex. People who expect applications to work with minimal intervention on their part are not going to take advantage of creating scripts any more than they currently take advantage of creating set files to minimize the number of issues they run into with new applications. That’s not to say that customizations shouldn’t exist for both new and advanced users alike.
So what the heck is my point? My point is that someone stating an application is not accessible because it is not customized, or because set files aren’t available, are going to say the same thing if scripts aren’t available. When in fact, an application’s accessibility is based more on the knowledge of the application and the knowledge of Window-Eyes. Even with sets or scripts, there’s still a learning curve when discovering how to use the features built into the customization. You’re going to spend time learning something: set file features, or Window-Eyes features. One of those will give you access to one program. The other will give you access to every program.
To take that a step further, making many of the applications listed in the "inaccessible application list" more functional can be done today with set files. Everyone is waiting for scripting. And if it shows up one day, everyone will stop waiting for scripting, and instead start waiting for scripts. My argument here (I fear it’s getting lost) is that until Window-Eyes does everything but wash your socks, I think it behooves people to get the most out of the documentation, the website, and training courses that we offer. Window-Eyes works with more applications right out of the box, even if those applications aren’t customized. We’ve heard countless stories from people using the competition who claim that they can’t even do basics things (like navigating an application with the mouse) without some kind of scripting. That’s very telling to me.
Is there still work to do? To quote Mike, "abso-freakin-lutely." But that doesn’t mean anyone is out of luck now. In fact, your chances of getting at an application are better with Window-Eyes than anything else. I base that statement on what I hear first hand from counselors and trainers a lot: if you use JAWS without any scripts, and Window-Eyes without any sets, in several different types of applications, Window-Eyes always provides consistent access JAWS does not. That’s more of a philosophy difference than something that’s right or wrong. But I believe it puts the "inaccessible application list" in perspective.
