Curtis Chong

Curtis Chong

Microsoft Active Accessibility Called into Question
by Curtis Chong

From the Editor: Curtis Chong, Director of the Technology Department at the National Federation of the Blind and President of the NFB in Computer Science, sent a note to a number of Internet mailing lists on November 24, 1997. The note, which generated a flurry of supportive responses on the Internet, raised questions about Microsoft's true commitment to its Active Accessibility® applications programming interface, a highly-touted (by Microsoft, at any rate) strategy to improve access to Microsoft and other graphical applications. According to information received by Mr. Chong, the group developing Microsoft Office® was not eager to rely solely upon Active Accessibility® to pass important information to screen-access software used by the blind. Instead the group wanted screen-access vendors to use object models (a way of communicating between programs) that had already been installed in the Office® product. Mr. Chong pointed out in his note that within the blind community support for Active Accessibility® had been slow in coming, but now that Microsoft had gained grudging acceptance for this approach, the company should require all of its development groups to make full use of it.

On the same day Mr. Chong posted his note, he received a call from the Microsoft accessibility team. Apparently they considered his note inaccurate—or at least a misrepresentation of the true state of affairs regarding Active Accessibility® and its use by the Office group. Much of the information supplied to Mr. Chong was off the record and therefore cannot be discussed. Mr. Chong offered to correct publicly any mistakes that he might have included inadvertently in his note, but only if the accessibility team could supply him with enough un-classified information to explain the corrections. Since they were unable to do so, it seems to us that Mr. Chong's public statement still stands. Here it is:

On Saturday, November 15, 1997, I received an e-mail note from Steve Sinofsky, general manager of the Office Product Unit at Microsoft. The subject of the note was the accessibility (to the blind) of current and future versions of the Microsoft Office® product suite. Office® includes such things as Microsoft Word® (word processing software) and Excel® (spreadsheet software). It is definitely a product that employed blind people want and need to use, and it should be one that we could enjoy using at home.

As background I should point out that for the past couple of years the accessibility team at Microsoft has been working hard on Microsoft Active Accessibility® (MSAA). This is an application programming interface (API) which is designed to simplify the task of communicating between screen-access software and application programs. The concept behind MSAA® is that, if an application such as Internet Explorer®, Word®, or Lotus Notes® chooses to use nonstandard methods of displaying information on the screen, it can still tell the screen-access program what is happening in a way that it can understand. Active Accessibility® took years for Microsoft to develop. The actual code was released in May, 1997.

Ever since the Microsoft Summit on Accessibility, held in July of 1995 (and possibly before then), Microsoft (at least its accessibility team) has been touting the virtues of MSAA®. In addition to promoting its use by developers within the company, the team has been evangelizing MSAA® to such prominent institutions as the Lotus Corporation, IBM, and others. It has also been pushing MSAA® with blind consumer organizations and developers of screen-access technology. This effort was apparently successful. We began seeing support for MSAA® in newer versions of screen-access software, for example, in JAWS for Windows® Version 3 (from Henter-Joyce), WinVision 97® (from Artic Technologies International), and Slimware Window Bridge® (from Syntha-Voice Computers). In fact, if it were not for MSAA, Office 97® would not be accessible to the blind today.

In his note Mr. Sinofsky casts serious doubt upon the entire Microsoft MSAA® effort. Here, in part, is what he said:

"We all agree the work that MSAA® demonstrates is in the right direction. But as I tried to indicate, there are limits to what an existing piece of software can do to integrate MSAA®. If I were writing a new application from scratch, there is absolutely no doubt I would use MSAA®. On the other hand, Office® is a huge and frankly not very pretty suite when viewed from the inside, and there are some things that will just not be practical from a pure engineering point of view. Please note this is not a resource issue, but one of just being able to make something function as specified.

We have spent about ten years working on the object models for our (Office®) applications. Today the object model is used as a programmatic way to control the application from outside the application's user interface. As I mentioned, this is the solution developers and even our own testers use. This object model is well understood and has been an investment of hundreds of person-years over at least four releases of Office®. As an example of this object model, the accessibility vendors all use our hooks in the product today for reading dialog boxes. By using the object model for accessibility, systems are assured a stable platform to work with the rich information it supplies. We are choosing to leverage this (object model) because we think it is the best way to achieve our shared goals. The alternative to this is to expose only the textural information of Office® document content (no image or location information) through the current MSAA® standards.

I realize that MSAA® is significant work for vendors, but it is not a magic solution. In programming terms it is necessary, but not quite sufficient for an application having the complexity of Office®. Frankly, I would be concerned that, by directing our efforts towards a specific implementation of accessibility, we would not only fail to make progress soon enough, but will more than likely take steps backwards. Since we share the same goal of making Office more accessible and we are again increasing our resources and commitment to this issue, I think it would be best if we can just agree on that high-level goal and not a specific implementation.

We committed at the forum (Microsoft Summit on Accessibility) two years ago to work more aggressively with the vendors that support accessibility. We have done that. Realizing that we could do better, we have been working with these vendors even earlier to support the next release of Office®. In fact, we have a mini-summit with several of them scheduled in the near future. You are certainly welcome to participate if you would like. Of course the goal is to support them as much as possible so they are able to release their systems closer to the release of Office®."

That was Mr. Sinofsky's note, and it gives rise to a number of questions.

First, regarding the Office® object model, did Mr. Sinofsky have any idea two years ago (at the Microsoft Summit on Accessibility, for example) that MSAA® might not be the optimal solution for access? One is tempted to wonder why this problem was not brought to the fore at that time instead of waiting until now to spring this on a community which, heretofore, was prepared (albeit grudgingly) to endorse the whole MSAA® package.

Second, if the Office® development group uses its object model in lieu of a full implementation of MSAA®, what does this say about the use of the highly-touted MSAA® with regard to other Microsoft applications? What does this say about the use of MSAA® by other companies—companies which undoubtedly have software just as convoluted and just as difficult to retrofit as the Office product suite?

Finally, how many different object models will screen-access vendors have to develop interfaces for? Today it might be Office®. Tomorrow it could just as easily be another suite of software— perhaps the hottest data base program or a spreadsheet package which we must use in order to keep our jobs. When will it end?

There are those who have said that we, the consumers, should not be telling Microsoft what specific development strategies it should use in support of accessibility. In fact, Mr. Sinofsky wants us simply to agree that in principle Office® needs to be accessible to the blind. He wants us to leave the specific details up to him, his engineers, and the screen-access vendors. Looking at this in a broader context, one is reminded of some of the more repressive and paternal institutions, who would much prefer blind consumers to sit back and let the service providers "handle it." Well, I don't buy it!

Mind you, I am not interested in telling Microsoft how to write programs. Nor am I interested in pushing one development strategy over another. What I want is accessibility to Microsoft software and, for that matter, accessibility to other programs written to run in the graphical (Windows) environment. For the past few years Microsoft, through its accessibility team, has been aggressively promoting Active Accessibility® as the best long-term solution to solve our accessibility problems. The skeptics among us (myself included) took some convincing, but we ultimately went along with this approach. Now the Office® group, through Steven Sinofsky, tells us that MSAA® is not the optimal solution for access to Office®.

I for one am not willing to accept this argument—not because Mr. Sinofsky isn't technically correct, but because of the long-term ramifications that accepting the Office® object model will have on the wide acceptance of Microsoft Active Accessibility®. If the Office® group is permitted to go ahead with the approach Mr. Sinofsky recommends, then other companies will begin to find excuses for minimizing their support for MSAA®. Yes, I acknowledge that MSAA® may not be the best approach technically. But today it holds out the best promise for true access to a wide variety of applications. Instead of abandoning MSAA® in favor of another object model, the Office® group should use MSAA® as it exists today and work with the accessibility team to improve it.