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.
Drawbacks
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.
MSAA Newsletter
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: <listserv@announce.microsoft.com>. Include the following command in the body of your message: <Subscribe ablenews>.
Future Prospects
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 <lazzaro@world.std.com> or on the Web at <www.world.std.com/~lazzaro>.
