The Right (or Required) Tool for the Job: Microsoft Developer Tools and Screen Readers
If you are not a programmer, should you care about developer tools? Have you ever bought a piece of software and found that it worked very badly with your screen reader? Likewise, have you found an application that was extremely speech-friendly without any effort on your part? How do these things happen?
Sometimes a program works well because the people who made it put in special effort and took pains to be sure it would be accessible to people with visual impairments. It is more likely that, any time you buy a piece of commercial software, the developers were substantially ignorant of the existence of computer users with visual impairments, let alone the details of what we like to see in software.
The specific tools programmers work with make a big difference in what the final application or utility will be like. For example, screen readers work well, generally speaking, with applications that use "standard controls." If the tool a programmer uses incorporates these standard controls, then the resulting application will likely be more accessible.
See the sidebar "What Are Standard Controls" for more detail.
Users who rely on the keyboard instead of the mouse, including blind users, need keyboard access built into the software. If the developer tool makes keyboard access automatic, then the resulting application will likely be more accessible. I will look at some of Microsoft's developer tools to see what they provide that lends itself to or impedes speech-friendliness.
What about blind programmers? A significant number of employed people with visual impairments are involved in the computer industry, many as programmers and software designers. Are Microsoft developer tools friendly to these programmers throughout the development process? I will try to answer that question, too.
What Is a Developer Tool?
When programmers begin to create an application, they have to start somewhere. Many factors are considered when programmers choose a programming language and the software tools that will be used to manage the project, compile and test the code, and help in the layout of user screens and management of the elements of the program. An important consideration is how much the developer tool software will do for the programmer. The more the tool does, the less programming time is necessary. So, the trend has been for developer tools to provide more automatic creation of major elements of applications.
Microsoft makes, or has a lot to do with, several developer tools. One major product, Microsoft Visual Studio, is a suite of tools that can also be bought separately. For our direct testing, we used Visual Basic 6.0 Professional, Visual C++ 6.0, and Visual FoxPro 6.0. These all came bundled as Visual Studio and have undergone several service pack releases in the past 18 months.
In the current version of Visual Studio, each tool has its programming language and its own environment. The place the programmer goes to lay out screens that the user will see, write code, and test programs is different for each program. Microsoft announced more than two years ago that it planned to move all of the Visual Studio (Developer Studio) tools to one common environment, but the current versions share little.
One characteristic shared by all versions, however, is their high degree of "visualness." The default screen arrangements have many windows displayed simultaneously, and the user is able to drag items around easily, at least if he or she has fairly good eye-hand coordination. The general look of the default screen layout is busy, and browsing it with screen reader review commands does not result in much meaningful information. At first perusal, it would be easy for a screen reader user to conclude that this was a hostile environment. But don't give up too quickly. The work spaces are also highly flexible, so most working preferences can be accommodated, allowing better arrangements of the default screen layouts. See the longer version of this article for details at <http://www.afb.org/technology/prodevals/msdev.html>.
Programmers and would-be programmers who dive into one of these environments might be overwhelmed by the complexity of the screens, the mouse orientation of the documentation, and the enormity of the task of making the transition from a text-based environment to a visual one. How do they do it?
I sent a short questionnaire to the people in the American Foundation for the Blind's Careers and Technology Information Bank (CTIB) who had listed Visual Basic, Visual C++, Visual FoxPro, Visual Studio, or Developer Studio among the products they use. The CTIB includes about 140 people who are programmers or software developers of one sort or another, but only a small number responded to the quick questionnaire, possibly an indication that most visually impaired programmers have not taken the plunge into the Visual environment.
My conclusion, based on the responses from the CTIB members, on my own wranglings with Visual Studio, and on the tearful calls from mainframe programmers making the switch? This stuff is hard to learn and there isn't much out there to help. At the end of this article, I will list some of the "Internet resources" that I have found useful, but there are not many.
How accessible are applications designed with these developer tools? Alas, database access with screens created in Visual FoxPro are a near disaster. It is possible to use screen reader tricks and features to get many data entry fields talking, but many will never speak well, and FoxPro does not make adding keyboard navigation to your program easy. If you have an application you want someone to create for you, leave Visual FoxPro 6.0 out of the running.
Visual Basic 6.0
Most interactions between users and Visual Basic programs is done in "forms." These are more or less like application windows or dialog boxes and may contain a wide variety of controls. Each form is a separate window and is perceived as such by screen readers, a good thing and one to look for when choosing a tool that creates speech-friendly applications.
Many Visual Basic controls look and behave more or less like standard controls, but they are actually nonstandard. They can be reclassed, however, so the commonly used ones present no major problem with the three screen readers that have this capability. However, some screen readers had trouble knowing which label went with which control, and Visual Basic does not give much guidance. If you are creating a Visual Basic program and want it to work with all screen readers, duplicate the label of the current item on the status line. That way, if the screen reader can figure out that the text to the left of the text box is the prompt, good; if not, the user can set the screen reader up to read the status line.
The addition of keyboard access to Visual Basic program features is fairly straightforward. When menu items are added, a place for the programmer to select an accelerator key (such as Control-N for New) is presented. Of course, the programmer can skip this step. Likewise, when a control or menu item is captioned, it is easy to designate shortcut keys by underlining a letter such as "N" in the menu selection "New." Inconsiderate programmers might also omit this slight bit of work.
Some powerful and useful Visual Basic controls do not offer keyboard access automatically. One noteworthy problem is the data control, which displays arrows on the screen and provides functionality to move through the records of a database, but by default only allows this to be done via the mouse. The programmer must take several extra steps to allow the keyboard user to step through the records or jump to the first record.
Applications Created Using Visual C++ 6.0
Visual C++ is one of the things the big kids use to write real programs. So, what has been your experience? Judging from the applications you have worked with, is it easy, or automatic, to create accessible applications using Visual C++?
The controls available from the Controls toolbar are standard. Placing them in your project gives you program controls that any screen reader knows how to handle and skilled users know how to manage. However, Visual C++ has loads of other controls available, and the world is filled with more that the programmer can choose from (see the sidebar for more detail). So, watch what you are doing.
Visual C++ gives the programmer ample opportunity to build in keyboard access. The uninformed programmer, however, can cut corners and skip keyboard access.
Microsoft Active Accessibility
Imagine you have hired a programmer to create a spectacular, feature-rich, accessible application. Should you insist on MSAA? Should you suggest MSAA? Should you find out what it is? (See "Taking the Mystery Out of Microsoft Active Accessibility" in this issue to answer to this last question.)
One of the ideas behind MSAA is that the control can give the screen reader information. A custom control that uses MSAA can tell a screen reader that also uses MSAA "I am a check box labeled 'Print Entire Document' and I am checked." A standard control, in most cases, can also give a screen reader that same information, and it can do so quickly and efficiently. Also, the programmer does not have to know what MSAA is.
But what if the programmers you have hired really, really need to use controls that are not among the standard ones we love so much. Is it a lot of trouble to ask them to use MSAA? The short answer is yes. The long answer is, yes, if they are using Visual C++, are skilled at what they are doing, and might even understand how much trouble it is going to be for the end user if they don't add MSAA. Besides, you are paying them by the hour.
Programmers using Visual Basic 6 might find adding MSAA to their project to be an overwhelmingly cumbersome imposition. Visual Basic 6 does not make it easy to add MSAA, and I have found almost no documentation on how to do it. If your programmers plan to use Visual FoxPro 6.0 to build your application, start the hiring process over again.
Buying a tool? Buying a screen reader to use with the tools you are using? Let's go through a quick list of possibilities. If you are a programmer considering switching to Visual C++ from some other flavor of C or C++, go for it. It will be challenging, but it is doable. If you need to choose a screen reader and have the universe to choose from, try JAWS for Windows, Window Bridge, and Window-Eyes—in that order.
If you have some programming skill, or would like to have, and you are considering using Visual Basic, take the plunge. It is daunting at first, but a lot of computer skill, a lot of screen reader skill, and some help from other programmers will get you through it. For a screen reader, try, in this order, Window Bridge, JAWS for Windows, and Window-Eyes. Need I say more about Visual FoxPro 6.0? Try any screen reader you like, maybe you will have better luck than I did.
If you plan to use programs written in Visual C++, choose your screen reader for these programs the same way you would for any software. The screen reader you are most comfortable with now will probably be the best one for you.
If you are using a program created in Visual Basic, you will have very good results with the latest versions of Window Bridge, Window-Eyes, and JAWS for Windows. If you plan to use outSPOKEN or WinVision or an older version of one of the screen readers, make sure prompts appear on the status line so you have a consistent place to look for them.
If you would like a lot more detail about these Microsoft developer tools and how they work with screen readers, read the full version of this article at <http://www.afb.org/technology/prodevals/msdev.html>.
Program-l is, in my view, the best listserv on the Internet. If you are not a programmer, you probably won't agree, but if you are you will find other people in your situation pooling their skills and generally raising the overall skill level. To subscribe, send a message to <firstname.lastname@example.org> and in the body of the message put the line: subscribe program-l with your name on the same line.
A valuable site, if you are interested in software accessibility, is Microsoft's site on the subject at : <http://www.microsoft.com/enable>.
If you are a programmer or working with one and want help in making it accessible, spend a few minutes (weeks) with the document "The Microsoft Windows Guidelines for Accessible Software Design," which can be found at: <http://www.microsoft.com/enable/dev/guidelines/software.htm>.
Users and trainers looking for a comprehensive list of keyboard commands for Windows will find one at: <http://www.microsoft.com/enable/products/keyboard.htm>. If you are a beginner, you will find this to be a frightening document. Advanced users will be delighted to discover all those keyboard commands that are hiding in the operating system.
Are you looking for sources of accessible documentation for programmers, developers, and associated people? There is a goldmine on the EarthWeb ITKnowledge web site at: <http://www.itknowledge.com>.
Interested in databases and screen readers? Here are two articles published in the Journal of Visual Impairment & Blindness last year. "Windows Databases Used with Screen Readers: An Overview" can be found at: <http://www.afb.org/technology/prodevals/databases.html> and "Access to Databases: Which Windows Database Programs Work Best with Screen Readers?" is at: <http://www.afb.org/technology/prodevals/database.html>.
"For VB6 and VC6, the dev environments are not the only way to write code—the source in both cases is text, so developers can use whatever editor they are comfortable with, if they have difficulty using the ones included with the product. Future releases of Visual Studio will use one, very accessible IDE (Integrated Development Environment).
We are devoting a tremendous amount of time and effort to making both the IDE as well as the software it generates more accessible."
Previous Article | Next Article |
Table of Contents
AccessWorld, Copyright © 2002 American Foundation for the Blind. All rights reserved.