Firstreleased in 1991, Microsoft Visual Basic was a programming environment where one could build an application by visually creating the user interface first, and then adding code. In contrast, even the smallest Visual Basic basic programs could take reams of program code to write in C or C++. Visual Basic was extremely popular for business application programming. The language itself was an interpreted BASIC dialect, however speed was maintained through the use of reusable compiled libraries (DLLs and VBX controls). These however, limited application development to Microsoft Windows.
Visual Basic 3 was the most popular version under 16-bit Windows 3.1, while Visual Basic 6 was the most popular for 32-bit Windows 95/NT and later. After version 6, Visual Basic was replaced by Visual Basic .NET, an incompatible successor.
Microsoft Visual Basic 6.0, now part of Visual Studio, was the last version of the true "Visual Basic" product. It was extremely popular, and is still used in many businesses. It is the last that can create native 32-bit applications for Windows 9x and NT. The replacement product "
VB.NET" requires Dot Net, and changes the core basic language in such a way that it is difficult to port VB 6 applications.
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.
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.
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 .
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.
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.
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.
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.
3a8082e126