Caption: Is Microsoft an Access-Friendly Place to Work? Find Out from Brett Humphrey and Others.
In This Issue . . .
|Editor in Chief
||Crista L. Earl
Jay D. Leventhal
Just a few years ago, only those who were brave, foolish, or provocative would dare mention Microsoft among a room full of computer users with visual impairments. Anger, fear, and dread would take over the discussion. now, you are more likely to hear about tips, techniques, and ideas for running Microsoft applications such as Word, Excel, or even PowerPoint. Users' frustration remains, but the shift from recitations of nightmare scenarios to real world uses of such application shows just how far things have come.
Microsoft and developers of assistive technology have made great strides to meet the needs of computer users who are blind or visually impaired. The skill level of users working in the Windows environment has also markedly improved, leading to a far more positive climate for computer discussions.
As you have no doubt figured out, the spotlight of this issue is on Microsoft. It may be possible to use a computer without using a Microsoft product, but it is rather unlikely. Its operating systems (various flavors of Windows), productivity applications such as Office, and the Internet Explorer Web browser completely dominate their markets.
Choosing to focus on Microsoft was a daunting task. Obviously, we can examine only a few programs here. Windows, especially built-in accessibility features such as Magnifier, was an obvious yes. Likewise, we thought it important to give you some basics about Microsoft's Active Accessibility, the program that is designed to assist access software such as screen readers. Office is used so widely that we certainly wanted to look at the newest version. Although tools for developers may seem a bit far afield, these tools are critical components in developing software, so we wanted to examine their accessibility and how easily they produced accessible programs. Finally, corporations are made up of people, and we decided to talk to some of those working for Microsoft who are blind or visually impaired.
For numerous reasons, we have not chosen to address the potential ramifications of the antitrust case brought against Microsoft. First, the scope of this issue is already quite broad. It also seems premature to spend much time in speculation about the eventual outcome, not to mention possible penalties, of a case when the ultimate disposition is a long, long way off. However, it is hard to imagine the circumstances under which a breakup or imposition of restrictions on Microsoft could foster accessibility efforts. Whatever your views on Microsoft's behavior in the marketplace, we can all probably agree that anything that hinders the ability of those responsible for accessibility to work cooperatively with developers of Microsoft's operating system and applications would likely harm accessibility.
As always, I welcome your comments on our coverage of Microsoft and your views on how the company is doing. (As a matter of full disclosure, I should mention that I serve on Microsoft's Accessibility Advisory Council, which was established in 1999.)
Editor in Chief
Back to top
A Brief History of Microsoft and Accessibility
Microsoft was founded only 23 years ago, in 1977. It gained major recognition in 1981 when IBM introduced its personal computer, which used Microsoft's DOS as its operating system. The first version of Windows came along in 1985. A few years later, in 1988, the company added the first accessibility support program for Windows by incorporating work developed at the TRACE Center, a research and development center on accessible technology at the University of Wisconsin. Known then as Access Utility for Windows 2.0, the program improved the accessibility of Windows for people who are deaf, hard of hearing, or who have limited dexterity—by allowing alterations in the use of the keyboard and mouse, providing visual alerts for the computer's sounds, and making it possible to operate the computer through devices hooked to the serial port. In 1992, Microsoft established a full-time position focused on accessibility. For several years, Greg Lowney directed the accessibility effort. (Lowney remains part of the Accessibility and Disabilities Group.)
Access to Windows for computer users who are blind or visually impaired was a long time in coming. The first screen reader for a Windows operating system was not released until 1992 when Syntha-Voice Computers released SlimWare Window Bridge for Windows 3.1. It was developed without much help from Microsoft. (Syntha-Voice was also the first to offer screen reader access to Windows 95.) In 1991, Ai Squared offered the first magnification package for Windows, ZoomText-Plus, which provided access to Windows version 3. ZoomText later provided virtually immediate access to Windows 95.
In 1993, Greg Lowney responded to the growing concern about access to Windows in a message to the National Federation of the Blind in Computer Science (his message was published in a newsletter in 1994). He said: "I know that for many of you, Microsoft is a word not to be said in polite company. In fact, I'll even agree that much of the criticism has been earned." He continued: "Windows has probably done more than anything else to earn Microsoft the enmity of the blind community. Microsoft has been both hated and feared by many people because we were promoting a graphical operating system without making sure that it could be used by people who are blind, and the results have been disastrous for many people."
By 1995, Microsoft was making a much more substantial commitment to accessibility for the soon-to-be-released Windows 95. Increasing pressure had been orchestrated by blindness organizations, state agencies serving people who are blind or visually impaired (especially the Massachusetts Commission for the Blind, then led by Charles Crawford), and the National Council on Disability. Two states (Massachusetts and Missouri) openly pushed Microsoft to commit to much greater accessibility for Windows 95 or face possible refusals by those states to purchase the program when it was released. In July 1995 (just prior to the release of Windows 95), Microsoft hosted a megasummit for disability advocates and developers of access technologies. A corporate policy on accessibility was unveiled, and planned accessibility enhancements were discussed. At that time, Microsoft began to openly discuss its plans to produce software that would aid assistive technologies in gaining access to the operating system and applications. That program, now known as Microsoft Active Accessibility (MSAA), was finally released in the spring of 1997. (For more information about MSAA, see the article "Taking the Mystery Out of Microsoft Active Accessibility" in this issue.)
Monumental Failure, Great Leap Forward
Meanwhile, the intensity of interaction between the disability community and Microsoft settled down. Then, Microsoft released Internet Explorer 4.0 in the fall of 1997, and the blindness community faced a dramatic backward step in accessibility. After so many had come to appreciate the relatively good access afforded by the previous version of Internet Explorer, we saw just how tenuous accessibility could be. With one stroke, Microsoft had undone all the progress made to that point. Letters, E-mails, and phone calls converged on Microsoft and apparently got the attention of Bill Gates, then the company's Chairman and CEO. Microsoft employees now, only half jokingly, refer to "those dark days." The company promised to fix the problem, and although it took longer than they predicted, Internet Explorer 5.0 recaptured the accessibility high ground. To his credit, Gates agreed to address a group of advocates and assistive technology developers in February 1998 and did not duck from the company's failure. He took responsibility and set high goals for future accessibility.
Without doubt, the attitude about accessibility coming from Microsoft employees is far more positive than it was a few years ago. The defensiveness that characterized so many discussions in years past is gone. Accessibility has indeed become part of the company's mission, albeit a small part, and Microsoft developers readily seek opportunities to do more to address obstacles. Criticism seems welcome, developers are almost begging for users' feedback, and the number of employees working on access has dramatically increased, both within the Accessibility and Disabilities Group and in major product areas.
Microsoft has come a long way and has made the strongest, most visible commitment to accessibility of any technology company, but it is not difficult to argue that even more should be done. Windows CE does not contain accessibility features. Key applications such as Access are not nearly as accessible as they should be. Some other software, such as Encarta, has major accessibility problems. Even when significant progress has been made, new products are released without fully incorporating existing accessibility features. (For example, Windows Millennium probably will not include Narrator, the operating systems' built-in voice-output program.) Significant problems remain in Office and in developer tools, even though work has been done to improve the accessibility of these products. Assistive technology vendors generally commend Microsoft for the company's support, but they also note that support is uneven, depending on the application in question.
We know that pressure from advocates has made a difference in convincing Microsoft to do more at key points: first, around the release of Windows 95, and later, after the Internet Explorer fiasco. We have many champions inside the company, within the Accessibility and Disabilities Group and within some product groups. But these champions will need us to remain assertive in pushing the company to make good on its commitments and providing timely feedback on problems we encounter.
For those who really want to be in the know on what Microsoft is up to for accessibility, the company publishes a free electronic newsletter called AbleNews. To subscribe to the newsletter, send an E-mail to: <email@example.com> and write "subscribe ablenews" in the body of the message.
Back to top
When Is a Little Magnification Enough? A Review of Microsoft Magnifier
If you want to make the text or other items on your computer screen appear a little larger, Microsoft Magnifier may be the answer. Or, if you normally use a full-fledged screen magnification program, you may find this application helpful when you must use a different computer temporarily. First available as part of Windows 98, Magnifier has been improved in Windows 2000. So what is it and what does it do?
The Big Picture
Many full-blown screen magnifiers on the market are compatible with Windows operating systems, and they offer options like font smoothing, mind-boggling magnification levels, smooth panning, and an array of hotkeys. Most are also currently compatible with Windows 2000. But what if you don't need all of that? Why get a toolbox when all you need is a screwdriver? If all you require is a simple, temporary solution to make the screen more visible, Microsoft's Magnifier may be enough. This program has been offered in Windows 98 and is now also available in Windows 2000 Professional, a version of Windows that is designed for use on business desktops and notebook computers. This version of Windows 2000, a combination of Windows 98 and NT, should be an easy transition for Windows 98 users, and with the security of Windows NT, it seems like a worthwhile upgrade.
Windows 2000 Professional includes all the options available on the Magnifier for Windows 98 and two new options: Start minimized and Show magnifier. The Start minimized option allows the user to start Magnifier with the control panel minimized, and the Show magnifier option displays the Magnifier window along with the control panel.
This evaluation reviews Magnifier's options and its performance in Windows 98 and Windows 2000. The Magnifier for Windows 98 was tested on a Dell Inspiron 3500 Pentium II processor, and the Magnifier for Windows 2000 Professional was tested on a new Dell Optiplex GX1P with a built-in video card and sound card. It was evaluated using MS Word, MS Excel, and MS Internet Explorer 4.0. It was also tested on the non-Microsoft programs America Online 4.0 and Adobe Photoshop 5.0.
The Search for Magnifier
If you have never heard of Magnifier, you are not alone. Although Microsoft does have a Web site dedicated entirely to accessibility, which among other things, lists assistive technology resources such as vendors, Microsoft does not make a big deal out of announcing that it has Magnifier. On its Web site it treats the introduction of Magnifier as it would any other program included with Windows 98 and Windows 2000 Professional. The accessibility features are shown much more prominently on the actual systems. A user is more likely to see Magnifier while using the systems' online help or the start menu and through the Accessibility Wizard available in both operating systems than on the Web site. (The Accessibility Wizard helps users customize the Windows applications and accessibility options.)
No Frills Display Options
To open up Magnifier, press the hotkeys CTRL+ESC, followed by R, and then type in "Magnifier." Or, go to the Start menu, Accessories, Accessibility, then Magnifier. The Magnifier has up to 9x magnification, which is less than the full-blown screen magnifiers on the market, such as Dolphin's Lunar, which offers up to 32x. The Magnifier does not have separate options for display modes; however, the user can easily manipulate the Magnifier window into a split screen or static window anywhere on the display. After the program is closed, it remembers the last configuration of the Magnifier window until it is changed again. The default or standard mouse pointer that is used to resize the Magnifier window is so thin that most of the time it is not noticeable. However, to make it more visible, there are options to change the size and color of the indicator in the control panel's Accessibility options, Mouse menu.
A Cover Up?
A serious problem that occurs in both Windows 98 and 2000 is that the area of the screen the Magnifier window occupies is displayed as a gray area, obscuring anything under it. For example, suppose the Magnifier window is set as a static window at the center of the display and a window pops up at the center of the screen. The pop-up window will pop up behind the Magnifier window and will not be seen.
Playing Catch Up
Another problem in Magnifier for Windows 98 occurs when the Magnifier window is moved too quickly. It leaves a trail of multiple stationary windows that disappears when the window stops moving. This problem was fixed in Windows 2000. Also, in Windows 98, the magnified screen moves slightly more slowly than the unmagnified portion of the screen no matter what program is being operated. This problem was very apparent when Adobe Photoshop 5.0 was used to edit a picture. The movement of the tools for drawing or moving components was very choppy. This problem did not occur in Windows 2000.
Follow the Leader
The three tracking features available on the Magnifier are: Follow mouse cursor, Follow keyboard focus, and Follow text editing. The Follow mouse cursor option displays a magnified area by following the mouse pointer. In the Windows 98 version, there is noticeable flickering of the magnified screen when the mouse moves quickly over it. In fact, the mouse of the unmagnified screen flickers even when stationary. However, in Windows 2000 Professional, it was smooth sailing for the display and mouse.
The Follow keyboard focus option displays a magnified area that follows keyboard commands. For both versions of Magnifier, this option worked very well in Word; however, for the Windows 98 version, there were a few problems that occurred in Excel. When we tabbed to other cells, this option was not responsive. When the Tab key, as well as the Return key, was pressed repeatedly to move to other cells, the Magnifier did not follow the highlighted cell. The focus moved only after information was typed into the cell. This problem was fixed in the Windows 2000 Professional version.
The Follow text editing option follows text while a user is typing. This option worked well in all programs and for both versions. Magnifier does a good job of following other areas of focus, such as pop-up windows—for example the window that pops up in Word that asks if a user would like to save changes.
There are two options on Magnifier that aid in visibility: Invert colors and Use high contrast scheme. The Invert colors option is available in all screen magnifiers. This option, which inverts the colors of the Magnifier window, worked well in all programs. The High contrast scheme option displays a high-contrast color scheme for the whole display. On the desktop, however, the background is not affected; only the colors of the toolbars take on a high-contrast color scheme, and the text under the icons on the desktop appear white on a black block background. In Adobe Photoshop 5.0, there was a slight problem using the high-contrast scheme for the drawing toolbox. In the toolbox, the tools are shown as icons. When a tool is chosen, the icon is highlighted while the other icons stay dark. In the high-contrast scheme the dark icons are too dark to be seen.
So How Does It Measure Up?
In Windows 98 Magnifier has its share of problems: the limitations of the Magnifier window, the flickering of the magnified screen, the flickering of the unmagnified mouse, the delay for the magnified window to catch up with the unmagnified window, the defects in the Follow keyboard focus in Excel, and the inability to see the toolbox tools in Adobe Photoshop 5.0 while the high-contrast scheme is activated. With the exception of the limitations of the Magnifier window, all problems are fixed in Windows 2000 Professional.
Magnifier is easy to operate because it has far fewer options than full-fledged screen magnifiers; it is simple, especially in the way it allows the user to manipulate the Magnifier window into any size and position with just the mouse; and it is convenient since it does not need to be separately installed from the operating system and it does not require any special changes in the display properties of the control panel that other magnifiers require to be compatible with the system.
It is also important to note that it never crashed during testing, and Magnifier worked rather well even on the two non-Microsoft programs tested. Finally, since it is free, the price can't be beat.
Does Magnifier compete with a full-featured screen magnifier? Absolutely not. It is designed to help out in a pinch or for those users who do not need more than a minimal set of screen magnification features.
Back to top
Taking the Mystery Out of Microsoft Active Accessibility
If you use a Windows screen reader or other adaptive technology, the chances are good that you have been exposed to Microsoft Active Accessibility (MSAA). You may even have heard one of two opposing points of view. One view is that MSAA is the best thing since canned beer. The other view is that MSAA is standing in the way of a truer and better form of access just over the horizon. So, which statement is closer to the truth? I will try to answer that question and describe the basic features of MSAA, its pros and cons, and the audience for this evolving technology. I will conclude with some brief highlights about the next release of MSAA, Version 2.0.
What Does MSAA Actually Do?
MSAA helps hardware and software developers from going gray before their time by making it more straightforward to build applications that are accessible. Using MSAA, mainstream developers are able to create applications that more seamlessly interface with adaptive technologies. It serves end users by helping create more robust screen readers and adaptive solutions. But if you are an end user, you are probably unlikely to even know that MSAA is inside your computer, much less how it actually works.
The main mission of MSAA is to expose user interface control objects so that assistive technologies like screen readers and magnification packages can read and access them. If you were confused by the last sentence, fear not! Let me explain what this all means in plain English.
Before MSAA was available, screen reader developers had a difficult time extracting information from the Windows operating system to read the user interface. The typical method for getting programs to speak was to write special case scenarios for each program. The problem with this approach is that it is easily broken by the next revision of the software program, forcing the screen reader developer back to the drawing board to code a new set of special cases. This work is time consuming, and it rapidly exhausts resources. Special casing also resulted in applications that did not speak reliably, despite the best efforts of the screen reader manufacturers.
With MSAA in place, screen reader manufacturers now have a common platform on which to work, which makes the job of writing a screen reader easier and results in access to more information. MSAA allows the screen reader to reach behind the scenes and pull information that it needs out of the applications program and operating system. MSAA also allows applications to communicate directly with your screen reader to inform you of events that take place, such as when a new window opens and when a dialogue box appears. Thus, MSAA is a direct, two-way connection between mainstream programs and adaptive technology.
The Document Object Model: Competition for MSAA?
MSAA is of great benefit to developers and end users, but is it the only game in town? There is an old cliche that says that the good thing about standards is that there are so many to choose from. One potential competitor to MSAA is known as the Document Object Model. DOM, though not specifically developed for adaptive technologies, allows screen readers and other adaptive technologies to gain information from an application about the state of its controls, menus, and other user interface objects. Some developers in the adaptive technology arena are using DOM to successfully extract information from programs in a manner that appears similar to MSAA on the surface. So if the DOM has what we need, then why not use it instead?
The answer is simple. The DOM differs from one application to another, and not all applications possess a DOM. Even if an application has one, there is no guarantee that the specifications will be published to make it useable. Moreover, the operating system does not contain its own DOM because DOMs are available only in select applications such as Word, Excel, and Access. For these reasons, MSAA is the clear choice, since it provides a single mechanism for accessibility in both applications and the operating system.
How MSAA Works
This section describes the gears and levers under the hood. I will keep it short, but you have been warned.
Microsoft released version 1.0 of MSAA in May 1997. The current version, 1.2.3., was released in August 1999. (MSAA 2.0 is apparently nearing completion.) MSAA is bundled with Windows 98, Windows 2000, and Windows Millennium. For Windows NT 4.0, MSAA was included in Service Pack #6. It was not bundled with Windows 95; however, many screen readers and adaptive software packages will include MSAA when you install them, or you can download MSAA from the Microsoft Web site.
MSAA is based on COM, the Component Object Model, which underlies the Windows operating system. (COM is a method for the operating system and applications programs to pass blocks of information back and forth.) MSAA is essentially a client server mechanism. If the "client server" analogy makes you think of a "local area network" then you are not far off the mark, since MSAA functions as an accessibility server. Again, the main mission of MSAA is to provide access to information displayed on the screen and all the controls and menus that you use to operate your favorite program.
But let's step back a bit. What makes a program inaccessible from a screen reader user's point of view? One key factor is a program's use of nonstandard controls. Screen readers have trouble handling nonstandard controls because the screen reader cannot reliably find the control's label and description. MSAA exposes this information so that controls can be seen and manipulated by screen readers and other assistive technology. (For more on standard and nonstandard controls, see the sidebar in "The Right (or Required) Tool for the Job" in this issue.)
When you use your screen reader to explore a menu or control that includes MSAA, you are sending an MSAA query to the application. In other words, the client (your screen reader) communicates with the MSAA server built into the applications program and asks about the name, location, and state of the current control. The MSAA server responds to the query with the information that the control is a button and that it is currently inactive, producing verbal output such as "Print" or "Grayed." "Print" refers to the name of the control, and "Grayed" tells you that this control is grayed out and thus inactive. Screen magnifiers can also take advantage of MSAA for such tasks as tracking the Start menu, toolbars, and menu bars in applications such as Word and Excel.
MSAA can also tell you what functions can be performed by a control object (a label that refers to things like menus, toolbars, dialog boxes, and buttons that let you control your software). These control objects have "methods" or functions that they can perform. Your screen reader can query the application about these various functions and cause them to take effect. For example, when a dialog box with two choices appears in the application you are using, your screen reader queries the MSAA server to ask which one of the two choices is the default item. You can then use the appropriate key command from your screen reader to read just this piece of information on demand.
In addition to these functions, MSAA can also extract other information from the operating system, such as the name of the window that currently has the focus. The MSAA server can also notify MSAA clients when objects have changed, which is useful when an object is created, destroyed, or has changed location. Objects can be menus, tool tips, dialog boxes, and so on.
Screen reader developers are generally supportive of MSAA, but there are also unfortunately some drawbacks to the current system. For example, vendors complain that MSAA is not consistently implemented throughout Microsoft's operating systems and applications. This problem forces vendors to use expensive "special case" solutions when MSAA is unavailable or not reliable. To make matters worse, according to many developers, MSAA is not well documented, making it difficult to learn and implement. Yet developers gave Microsoft high praise for technical support in providing rapid responses to their questions. Microsoft has also implemented programs such as the MSAA beta program to help developers learn about MSAA and how to work with it. Another problem with MSAA is that not enough people know about it. I would urge the company to evangelize MSAA more, to spread the word about its capability aggressively to mainstream software developers.
Microsoft publishes a free newsletter that covers accessibility efforts at the company. The newsletter contains technical information useful for developers and is available via E-mail. To subscribe, send E-mail to: <firstname.lastname@example.org>. Include the following command in the body of your message: <Subscribe ablenews>.
With the next release of MSAA just over the horizon, what kind of improvements can we expect? The most interesting upgrade appears to be that MSAA 2.0 will have the ability to provide information about documents, similar in some respects to the information available from the DOM. Thus, MSAA 2.0 will improve the ability of screen readers and other adaptive technologies to pass on key information such as bold, underline, and which text is selected. It will also allow screen readers to identify and handle graphics, sounds, videos, databases, tables, and other items embedded within a document. For example, when you encounter a spreadsheet within a Word document, your screen reader will announce that you are landing on a spreadsheet when you move your cursor to that portion of the document. You will be able to read the spreadsheet portion of the document like any other spreadsheet, until you cursor beyond its boundaries. MSAA 2.0 will also support additional nonstandard controls, and some known bugs from the 1.2.3 version will be cleared up.
But the future of MSAA still depends in large degree on the efforts of the disability community and how committed we remain on access issues that affect us all. If the community grows complacent, it is likely that many of the gains we have achieved today may fall by the wayside. We enjoy more access today than we have ever had before, and it is easy to grow apathetic under these circumstances. But if we remain engaged, we can continue to improve on the accessibility that has been built. For information specifically on MSAA, see <http://www.microsoft.com/enable/msaa/>.
Joseph J. Lazzaro is Project Director for the Adaptive Technology Program at the Massachusetts Commission for the Blind in Boston. He is also a freelance science and technical writer who specializes in the field of assistive technology. He is author of two books on the subject of assistive technology: Adaptive Technologies for Learning & Work Environments (American Library Association) and Adapting PCs for Disabilities (Addison-Wesley). He can be reached by E-mail at <email@example.com> or on the Web at <www.world.std.com/~lazzaro>.
Back to top
How Accessible is Microsoft Office 2000?
If you use a computer, chances are pretty good that you use one or more of the applications that are included in Microsoft's Office suite. Blind users suffered substantial losses in productivity when Office 97 was launched amid much fanfare. Screen readers have improved since then, and Microsoft has announced accessibility enhancements designed to make Office 2000 easier to use for people who are blind or visually impaired . So is Office any better?
Surely you remember the fun you had with Office 97. It was possible to read text in Microsoft Word 97. However, underlined text was invisible to screen readers, and menus and dialog boxes were silent. The unanimous outcry from blind users, organizations of and for the blind, and screen reader manufacturers culminated in threats from the state of Massachusetts to not buy Microsoft Office if the program did not improve dramatically.
Microsoft enhanced its accessibility team and developed Microsoft Active Accessibility (MSAA), programming enhancements designed to improve access to applications. For a user to benefit from MSAA, it is necessary for it to be incorporated into both the application and the screen reader. Screen reader manufacturers that incorporated MSAA were able to begin to function in Office 97 menus and some dialog boxes. However, since Microsoft had not completely implemented MSAA in Office 97, many controls, including most of those used in Access 97, still did not work with speech. The developers of Office 2000 promised to expand the use of MSAA into Access 2000 and into many of Office's nooks and crannies where screen reader users previously could not go without tricks that only the experts among us know. Screen readers that use MSAA as their major way of obtaining information from Office applications include: Window-Eyes from GW Micro, Window Bridge from Syntha-Voice, and WinVision from Arctic Technologies. (For more about MSAA, see "Taking the Mystery Out of Microsoft Active Accessibility" in this issue.)
A Different Approach
JAWS for Windows from Henter-Joyce uses MSAA only in Office menus and takes a different approach elsewhere. Henter-Joyce chose to use Microsoft's Document Object Model (DOM). The DOM is typically used to allow one application to control another—to allow Word to print labels from names and addresses stored in Access, for example. Jaws uses the DOM to get more complete information than MSAA can supply in many cases—to read the cell address, value, and format in Excel, for instance. Using the DOM involves a lot of time and programming. You can think of it as almost having to write a separate screen reader for each application. Querying the DOM requires more computing power than does MSAA, as well.
Time and Money
No matter which method they choose, screen reader manufacturers must spend a huge amount of time making their products work with Office. Office applications are among the most popular on the market and, naturally, the number one priority is to get your product to work best with the most popular programs. But, since those programs use nonstandard controls, almost none of the work done by screen reader manufacturers can be used in non-Office applications. Also, this work is serious programming that must be done by someone thoroughly familiar with that screen reader's internal workings, whereas an advanced user can develop a configuration file for another program that uses standard controls.
Working with MSAA
So a user whose screen reader is using MSAA in Office should get the information at least as fast as they do in applications that don't have something assisting the screen reader, right? Those of you who use screen readers that use MSAA extensively know that is not the case. It probably sometimes seemed as if you could have gone to the water cooler and back before your screen reader announced whether a checkbox was checked or unchecked. That kind of problem is the result of the screen reader waiting for MSAA to convey that information from Office's nonstandard controls. Of course, that situation is better than not knowing the current state of the control or even that there was a control there at all. But using the current version of MSAA in Office makes you feel as if there is another force present, in addition to you, your screen reader, and the application you are using. And that is because there is.
Improvements in Office 2000
Once MSAA brought speech to Office 97, users discovered other problems. One involved text disappearing, applications being sluggish, and strange sounds coming from the computer. It was the Office Assistant, an animated paperclip that could be helpful in answering questions for sighted users, but can also be a real screen reader stopper.
Usher, This Man Is Annoying Me!
In Office 2000, there is an option to turn the Office Assistant off on the Help menu. It is no longer necessary to chase him around the screen using your screen reader's mouse commands. Then, once he is off, he stays hidden unless you actually choose the menu option to have him reappear.
The Help system is much improved and easier to use in Office 2000. Help is HTML based, so your screen reader can take advantage of the same features that work so well in Internet Explorer 5.0. You can Tab through items and select the one you want by hitting the Enter key. You can then hit your screen reader's feature that reads to the end of the document or use the arrow keys. So, knowing your screen reader's Internet Explorer commands is the key to finding information in Office 2000's Help.
Office 2000 still uses nonstandard controls. However, it is now more difficult to find controls that do not function properly. For example, the Go to dialog in Excel 97 was unusable with several screen readers, but it functions in Excel 2000. When you Tab around in a dialog box, such as Word 2000's Page setup or Font dialogs, buttons, combo boxes, and radio buttons are read. The current status of check boxes (whether checked or unchecked) is announced.
If you hit the Control or Alt keys in the spell checker in Office 97, all the buttons—Ignore, Replace, and Skip—disappeared and you had to select Undo to bring them back. In Office 2000, you can use screen reader commands that include Control, Insert, or Alt without interrupting the spell checker.
Office 2000 has a new clipboard toolbar. It allows you to copy or cut up to 12 items to the clipboard. (Who decided on 12?) It then informs you that if you add another item to the clipboard, you will overwrite the first item added. This clipboard toolbar also hides some of the text on the screen. You can turn toolbars off in the View menu, as well as navigate to toolbars with keyboard commands.
A Database By Any Other Name
Perhaps the most dramatic improvement in the Office suite was in Access. In Access 97, a great many controls were nonstandard, and few used MSAA to compensate. Most screen readers worked badly with Access 97, and some did not work at all and were not even able to detect the presence of much of the text on the screen. With Access 2000, Microsoft added MSAA to many dialogs and other key parts of the program, making those parts usable. Keyboard access to features previously available only via the mouse was also added. One noteworthy improvement is in the clearly documented way in which a keyboard user is now able to establish a relationship between two tables, a task almost impossible to do previously, even with the best screen readers.
Inappropriate Office Behavior
Office 2000 includes features designed to make the average computer user's experience more intuitive. Unfortunately, some of these features can silently alter a screen reader user's documents and leave you wondering just who is in charge. For example, Word does automatic formatting, for your convenience, that changes documents without warning you aurally. So, if you start making a list of items separated with blank lines, Word will silently number those items. Then, when you discover the numbers and try to remove them, the cursor will skip over them. The Search command will allow you to find and delete them.
You cannot work very long in Office 2000 without encountering a wizard. Whether it is the Import wizard in Access or the Pivot table wizard in Excel, it will appear and claim to be ready to help you complete the task at hand. Wizards are often confusing because it is not always clear just from listening what text is a prompt. The ideal wizard would be one that clearly tells you what options are available and does not engage in extraneous banter.
The Autocorrect function corrects what it decides are spelling and grammar mistakes in your documents. (Try typing Arctic Technologies and they'll seem to move to the North Pole.) You can turn this feature off in the menus. You can also turn sounds on, and Office will play a sound when it corrects you. You can download Office sounds at <http://www.officeupdate.com/2000/downloadDetails/sounds.htm?s=/downloadCatalog/dldWord.asp>.
In Word, the left-to-right positioning of the cursor is not shown on the status line. A sighted user can look at a column of text and say: "Okay, that's lined up correctly." However, your screen reader can't tell you the same information by reading the status line.
The Conclusion Wizard
Microsoft has followed through on its promises to make Office 2000 much more accessible than Office 97. The Office 2000 development team took a leadership role and worked with screen reader manufacturers and sought feedback from consumers and trainers at conventions and private meetings. The largest improvement was in Access, which went from inaccessible to somewhat usable. Henter-Joyce has done extensive work in Excel, and JAWS for Windows works better than other screen readers with that program. Word has become a much more comfortable environment in which to work.
Now that access to Office programs has improved, users must do their part. Open Excel and experiment with entering and reviewing some data. There are now screen reader configuration files for PowerPoint. Experiment with developing a very basic presentation. When we ask screen reader manufacturers why their products don't work better with Excel, Access, or PowerPoint, they say that only a few users request better performance in those applications. So let's give them reasons to continue to improve their products' performance with Microsoft Office and other applications.
"Regarding future plans of Office, we will continue to listen to our users and accessibility aid vendors to help improve our product. We are also working closely with the Active Accessibility team as they define MSAA 2.0, designed to address the need for support within the document area."
Back to top
Inside Microsoft: An Accommodating Workplace for People Who Are Blind?
Whether or not you like Microsoft and its products, there is no denying the fact that the company's interest level in making its products accessible to people who are blind or visually impaired has a direct impact on countless jobs. Many of those jobs are the jobs held by you and me and thousands of others who find the use of computers to be essential elements of our work. The Redmond, Washington, Microsoft campus has 19,418 employees (36,000 around the world) and includes more than 40 buildings over an area of more than 4 million square feet on the main campus and an additional 680,000 square feet across the highway. Exact counts are not available, but a large number of people with disabilities are on the payroll.
Four Microsoft employees who are blind or visually impaired spoke with me to provide an inside view of what it's like to work for the industry giant. Two work on making products more accessible, and two work in departments entirely unrelated to disability.
Doing Something About Accessibility
When Peter Wong first came to the United States from his native Hong Kong 20 years ago, it was with the plan of becoming a sociologist. Later, as he became increasingly interested in technology, he traveled to England to do graduate work at Cambridge in computer science. His first Silicon Valley employer hired him, he said, because "anyone who would change jobs midstream has to have guts. To do it and be blind as well showed real courage." When that job posed increasingly insurmountable barriers as a result of its graphical environment, Wong decided that he had a choice: He could either give up and go back to sociology or look for a way to help solve the graphical environment problem for himself and all blind people. Thus, in 1993, he joined Microsoft.
Initially, his role was to develop fax printer drivers—a task with no connection to adaptive technology. Wong believes, however, that a blind person working side by side with sighted engineers makes its own contribution to building accessibility, that merely by contributing in the workplace some progress is made. When an accessibility department was finally established in 1995, Greg Lowney (who had previously been the only employee addressing access issues) invited Wong to join the new team.
As a software test engineer for the accessibility group (which has grown from four to forty employees in just five years), Wong says his job is constantly changing. Currently, his focus is compatibility—that is, monitoring the compatibility between Microsoft products and assistive technology. That job requires the examination of three elements. The operating system, the third-party access technology, and the Microsoft application. All must be thoroughly reviewed separately and then made to work tightly together.
Encarta Online, for example, would be a typical starting point for his attention. To be accessible, it needs to work with screen readers such as JAWS for Windows and Window-Eyes, and then both elements need to work with Internet Explorer. Wong's job begins by explaining accessibility to the representative of Encarta, exploring features such as keyboard commands. He then works in the same way with the screen reader vendors and Microsoft developers to put the pieces together.
To do his work, Wong uses a variety of tools, rotating screen readers on a regular basis. JAWS, Windowbridge, and Window-Eyes get equal time and attention throughout his work week; although he is a braille user, he has not added a refreshable braille display to his workstation.
Not Just Playing Games
Brett Humphrey's only relationship to accessibility is as a user of assistive technology. His job at Microsoft—offered to him in 1998 following two successful summer internships—is to develop tools that are used by game developers. As a software design engineer for the product called DirectX, Humphrey is one of the first people to create the building blocks that allow game developers to write programs that work correctly.
As a computer science major at the South Dakota School of Mines and Technology near his birth place, Humphrey is grateful for the funding and accommodations he received from his state's Department for the Visually Handicapped. The accommodation assistance he received was extraordinary, he says, just as it has been at Microsoft.
Although he uses JAWS for Windows and DECtalk speech to help him read lengthy documents, Humphrey generally does his work visually. Two side-by-side 20-inch LCD panels make it possible for him to see more printed characters at a time. In addition to a closed-circuit television for enlarging hard copy print, Humphrey says that one of the most important accommodations made for him is the cabling of his laptop to others during team meetings. Since he is unable to see the large video monitor in a group presentation, cabling his laptop to the presenter's enables him to pull up the same information his team is viewing.
Behind that Windows Seal
Perhaps no one was as surprised as Loren Mikola to come to Redmond, Washington, as a Microsoft employee. Dropping off resumes at a job fair at Arizona State University, Mikola remembers a friend encouraging him to leave one with Microsoft. The next day he was called for an interview, and before long he was offered a job.
Mikola was particularly impressed with the level of accommodation provided by the company. All employees, he says, are assisted in finding housing and making the move. The company paid for his parents to stay one week to help him get settled and for an orientation and mobility specialist to familiarize him with his new location.
Mikola initially worked in designing databases and is now a software test engineer in the Windows Hardware Quality Labs. Mikola's team provides vendors with the Hardware Compatibility Test Kit showing the steps needed to obtain a Microsoft "seal of approval," ensuring that outside products are Windows compatible.
"Down the road there might be something I could contribute in the area of accessibility," Mikola said, "but for now, it's a great feeling to be working in the mainstream area of the company."
In terms of accommodation on the job, Mikola echoes his colleagues with praise for the company's flexibility in providing necessary tools. "I basically just asked for what I needed and it was here," he said. In his case, those accommodations include JAWS for Windows 3.5, DECtalk Express, and an RBT40 braille display. Although he prefers speech for rapid reading, the braille display is a must for Mikola when he is writing programming code. In a work environment in which all focus is on technology, he says reading conventional print is a minimal requirement. "I've probably had five to ten pieces of paper to handle in the time I've been here," he says.
Fixing Internet Explorer
Mia Lipner, the most recent hire among those interviewed for this article (and with arguably the most fun job), came to Microsoft via perhaps the most circuitous route. An English major from Princeton University, this former New York City public school teacher and Seattle, Washington, adaptive technology trainer just "happened to be in the right place at the right time" when Microsoft was searching for someone to test the accessibility features of Internet Explorer.
"There's a new version of Internet Explorer every day," she explains, "and my job is to do whatever research necessary to see that it's accessible with popular screen readers."
Her advice to others identifying problems with Internet Explorer or other Microsoft products is to be specific in identifying the problem. "If your screen reader won't read the control button after you've tried the Tab and arrow keys, tell us that," she says. "You need to have patience with yourself, the technology, and the people you're talking with to get it fixed."
On the issue of blindness itself, all four of these Microsoft employees believed that it is not an issue. "It doesn't come up much if you do your job well," comments Brett Humphrey. "If it did, I'd have an answer to the question!"
As for the future of blind accessibility in a Windows environment, Peter Wong sums it up this way. "Given the right tools, every human being has abilities that will blossom like flowers. In the computer world, that means that proper tools can enable us to cross many boundaries. When the Windows CE platform is applied to devices at home, for example, many household items will become usable… . On the other hand, after seven years I've learned that the world is built for sighted people. It is a fact in life. From a design point of view, we can create standards, but there are still many loopholes. The industry is market driven, and there will always be some gaps."
With the kind of talent represented by these four individuals who are blind, those of us waiting for the next Microsoft products can at least feel confident that there are dedicated insiders guiding the rest of Microsoft to better understand accessibility through direct effort and through example.
Back to top
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.
What are "Standard Controls?"
What is a standard control and why should you want one? How will you know when you see one?
The Windows operating environment has many resources built into it from which programs running under it can draw. This situation obviates the need for each developer to create a separate set of resources and promotes compatibility among running applications. One category of commonly available items is the control. Everyone who uses Windows is familiar with the edit box and the button, although non-screen reader users may not know what they are called. These and other controls are stored in two files named USER32.DLL and COMCTL32.DLL.
If a person designing a program wants the user to type in a word, for example, an edit box might be the type of control that would do the job. The programmer might use the standard, normal, edit box. In that case, any screen reader knows what it is. When you, the user, land on the edit box, your screen reader says something like "edit box" and usually reads the label, the text to the left of the edit box that is intended to give guidance about what the program wants the user to do. So, you might hear "User name edit box."
Why would a programmer use something other than a standard control? There are three possible reasons:
- The functionality the programmer wants to include in the program cannot be accomplished by using one of the standard controls.
- The programmer has included a third-party set of controls in the project. These third-party controls are widely available. Many are sold in packages to programmers , and others are distributed without charge.
- The developer tool being used includes controls which are not standard.
If a program uses a large number of "custom" controls, is this the end of the world? Fortunately not. Several screen readers have a feature that allows the user or someone else to tell the screen reader to treat a given type of custom control as a specific type of standard control. So, using JAWS for Windows, Window-Eyes, or Window Bridge it is possible (and easy) for the user to "reclass" a control so that a custom control that is labeled "Cancel" will be recognized as a button. Since programmers tend to recycle their custom controls, the screen reader will now treat all these items as buttons.
Although this reclass feature is powerful and I recommend that every user become familiar with it, it is not the ideal solution. First, not all screen readers have the feature, so a program that relies on custom controls will be inaccessible to some degree to some users. Second, it is not always possible to find a standard equivalent for a given custom control. So, reclassing the control may, in rare instances, make matters worse (fortunately, users can put the control back into its unreclassed state). Also, not all users are skilled enough in the use of the screen reader or Windows to successfully reclass controls.
Better that the program be constructed accessibly than that your grandmother be expected to change a ThunderListBox to a List Box.
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."
Back to top
Question and Answer
Question: I heard Microsoft makes something that speaks information about what's happening in Windows. Do I want this; should I get it?
Answer: You are probably asking about something called Narrator. First, let's be sure everyone knows that this product is definitely not a screen reader. Narrator comes with Windows 2000. You will need to have a functioning sound card to use it, but that is a small price to pay.
Narrator is a very cute, rather functional program. It starts up with a message telling you that you might want a more substantial screen reader, which is most likely true if you want to use a screen reader at all. Narrator is quite useful, though, when you drop by to visit your brother and he is pulling out his hair trying to figure out how to get something to work on the computer. You might just run Narrator and be able to give him a little assistance.
Does it really work? That depends on what you want it to do. It reads menus and dialog boxes in programs like Notepad, Internet Explorer, and the Control Panel. It reads text when you are using the arrow keys in Notepad and it reads Web pages in IE5 and lets you know what link you are on when you are tabbing around. It does not have many commands, so there is not much to memorize. It also does not let you do things like spell words or inspect punctuation. The command to read the text of an edit field reads the text in Notepad, as well. Interestingly, it reads all of the text, even the ends of lines that disappear off the right side of the window or the last lines that run off the screen.
The documentation is a little thin. In fact, I found two hot keys that did not seem to be documented anywhere. Alt-Home reads the title bar and Alt-End reads something near the bottom of the window, sometimes the status line.
How do you run Narrator? Bring up the Start Menu by pressing Control-Escape, then press "R" for "Run." Type "Narrator" and press ENTER. I think you will find it fun and useful, but don't abandon your full-featured screen reader. And absolutely never accept any suggestion from an employer or anyone else that Narrator makes a screen reader unnecessary.
Back to top
Credit Card Device
The IC eCommerce unit, a product of U.S. Netcom (New York, USA), in conjunction with Keycorp (New South Wales, Australia), is a point-of-sale credit card device that is designed to provide equal access to credit card transactions to people who are blind or visually impaired. The device has high-contrast, raised-letter function keys, a large, high-contrast screen, and a speaker that gives verbal confirmation of PIN entry and purchase amount. Contact: Ron Katz, U.S. Netcom; phone: 516-676-0006; Web site: <www.chargeforcharity.com>.
Access at Adobe
Adobe Systems, with support from Microsoft Corporation, GW Micro, and Henter-Joyce, recently announced its intention to support the Microsoft Active Accessibility Application Programming Interface in future releases of Adobe Acrobat software for Windows, which includes Adobe Portable Document Format. Contact: Adobe Systems; Web site: <www.adobe.com>; or GW Micro; Web site: <www.gwmicro.com>.
Eschenbach Optik of America has partnered with Telesensory to distribute Telesensory's Aladdin Companion video magnifier. The partnership will involve joint marketing efforts in North America targeting eye care and rehabilitation professionals. Contact: Telesensory; phone: 408-616-8700; E-mail: <email@example.com>; Web site: <www.telesensory.com>; or Eschenbach; phone: 203-438-7471; E-mail: <firstname.lastname@example.org>; Web site: <www.eschenbach.com>.
Voice Recognition for Math
MathTalk for the Visually Impaired is a mathematics program designed to convert voice commands into mathematical calculations and operates with ScientificNotebook, DragonDictate, Nemeth Braille Converter, JAWS for Windows, and refreshable braille devices. Contact: Metroplex Voice Computing; phone: 817-261-1658; E-mail: <email@example.com>; Web site: <www.mathtalk.com>.
Braille Scanning Software
Optical Braille Recognition (OBR) is a new Windows program that scans braille documents and converts them into print. It can scan single-and double-sided documents. Contact: Sighted Electronics; phone: 800-666-4883 or 201-767-3977; Web site: <www.sighted.com>.
Cake Talking is Dancing Dots' new tutorial for Cakewalk Pro Audio, software for creating music and sound on a computer. The tutorial costs $195 and operates with JAWS for Windows. Contact: Dancing Dots; phone: 610-783-6692; E-mail: <firstname.lastname@example.org>; Web site: <www.dancingdots.com>.
Verbal View of Word 2000 Tutorial is a generic tutorial for use with any screen reader. The cost is: cassette or standard print, $75; grade 2 braille or large print, $85; floppy disk, $45. For more information, contact: BRL, Inc; phone: 770-716-9222; Web site: <www.wyfiwyg.com>.
In conjunction with the Josephine L. Taylor Leadership Institute held in Dallas, TX in March 2000, AFB (American Foundation for the Blind) presented four Access Awards, which are given to people who strive to eliminate or reduce inequities faced by people who are blind or visually impaired. Among the recipients were: Dancing Dots, for its GOODFEEL braille music translation software; IBM Special Needs Systems, for its range of assistive technology products; and Pitney Bowes, Inc., for developing the Universal Access Copier System, a copier that uses assistive technology. Contact: AFB; phone: 212-502-7600; E-mail: <email@example.com>; Web site: <www.afb.org>.
At Telesensory, Edward (Ned) Long is the new president. Marc Stenzel is the new vice president of sales. Contact: Telesensory; phone: 408-616-8700; E-mail: <firstname.lastname@example.org>; Web site: <www.telesensory.com>.
At Arkenstone, Renee Clark is the new director of customer support. Maryanne Sember is the new manager of field sales. Contact: Arkenstone; phone: 800-444-4443; Web site: <www.arkenstone.org>.
Blazie's Technical Support Department has changed its telephone number to: 561-223-6443; the department can still be reached by E-mail: <email@example.com>.
Pulse Data International has moved to: 351 Thorton Road, Suite 119, Lithia Springs, GA 30122; phone: 770-941-7200; fax: 770-941-7722; E-mail: <firstname.lastname@example.org>; Web site: <www.pulsedata.co.nz>.
ALVA Access Group has moved to: 436 14th Street, Suite 700, Oakland, CA 94612; phone: 510-923-6280; fax: 510-451-0878; E-mail: <email@example.com>; Web site: <www.aagi.com>.
Dancing Dots has moved to: 1754 Quarry Lane, P.O. Box 927, Valley Forge, PA 19482; phone: 610-783-6692; Web site: <www.dancingdots.com>.
Back to top
July 17–21, 2000
International Conference on Computers Helping People with Special Needs.
Joachim Klaus, organizing committee, University of Karlsruhe; phone: 011-49-721-608-2760; E-mail: <firstname.lastname@example.org>; Web site: <szswww.ira.uka.de/icchp2000/index.html>.
October 19–21, 2000
18th Annual Closing the Gap Conference: Computer Technology in Special Education and Rehabilitation.
Closing the Gap; phone: 507-248-3294; Web site: <www.closingthegap.com>.
October 22–24, 2000
Access Expo 2000.
Julie Stein, ParaQuad Victoria; phone: 011-613-9415-1200; E-mail: <email@example.com>; Web site: <www.paraquad.asn.au/expo/expo.html>.
November 9–11, 2000
4th Annual Collaborative Assistive Technology Conference.
Colorado Assistive Technology Project; phone: 303-864-5100; Web site: <www.uchsc.edu/catp>.
November 13–15, 2000
ASSETS 2000, Association for Computing Machinery (ACM) Conference on Computers and the Physically Disabled.
ACM; phone: 800-342-6626 or 212-626-0500; Web site: <www.acm.org/sigs/conferences/assets00/>.
November 16–17, 2000
ACM Conference on Universal Usability.
ACM; E-mail: <firstname.lastname@example.org>; Web site: <www.acm.org/sigs/sigchi/cuuMay 17, 2000>.
January 20–22, 2001
Technology and Media Division of the Council for Exceptional Children (TAM) 2001: A Technology Odyssey.
Department of Special Education and Rehabilitation Counseling, University of Kentucky; phone: 606-257-2609; E-mail: <email@example.com>; Web site: <www.tamcec.org/tam2000.html>.
January 11–13, 2001
Technology and Media Division of the Council for Exceptional Children (TAM) 2001: A Technology Odyssey.
Department of Special Education and Rehabilitation Counseling, University of Kentucky; phone: 606-257-2609; E-mail: <firstname.lastname@example.org>; Web site: <www.tamcec.org/tam2001/index.html>.
January 24–27, 2001
Assistive Technology Industry Association (ATIA) Conference.
Shana Peake, Assistive Technology Industry Association; phone: 847-869-1282; Web site: <www.atia.org>.
August 3–5, 2001
2001: A Technology Odyssey.
Sponsored by the American Foundation for the Blind (AFB) and the Association for Education and Rehabilitation of the Blind and Visually Impaired (AER). Pittsburgh, PA.
Mark Uslan, AFB co-chair; phone: 212-502-7638; E-mail
Barbara McCarthy, AER co-chair; phone: 804-371-3661; E-mail: <email@example.com>.
Back to top
AccessWorld, Copyright © 2002 American Foundation for the Blind. All rights reserved.