Pros and Cons of Accessibility APIs: Notes on Peter Korn's Blog Post of 2/6

Since starting this blog, I have discussed a number of different AT products that run on the Microsoft Windows platform almost to the exclusion of Macintosh, GNU/Linux and any other operating environment that a person with a vision impairment might want to use.  I’ve also made mention of MSAA and the upcoming UI Automation (both Microsoft technologies) to the exclusion of the gnome accessibility project and the Macintosh Accessibility API for Apple’s OSX platform.  This exclusion stems from my own knowledge, which is almost entirely about Windows, and because Windows is the overwhelmingly dominant operating environment used in places of employment around the world.  I also entirely ignore AT products outside of those for people with vision impairments as I have virtually no expertise (outside of conversations with some vendors of such products who are also personal friends) in that area.

Peter Korn, Sun Microsystems accessibility architect and long time accessibility advocate, in his February 6 blog entry, makes note of this and offers a different opinion as to the cause of the continued accessibility problems that I described in the posting I wrote about the failure of competition in the AT industry.  Peter, as often is the case, brings out some very good points, some with which I agree and others, like the failure of competition to deliver better solutions to AT users, with which I disagree.  Peter also mentions my near total exclusion of operating environments from vendors other than Microsoft which I do hope to correct in this post and in others to follow.

Peter correctly states that in a later post about contextual information, I point out that MSAA, the accessibility API for Windows didn’t offer enough to make mainstream applications truly accessible and he goes on to say that a richer accessible API, like that being used by the gnome accessibility for GNU/Linux platforms, the Macintosh accessibility API for OSX and Microsoft’s upcoming UI Automation API will do a much better job.  I agree entirely with the assertion that better accessibility APIs built into the OS will make support for individual applications much easier and that AT companies will not need as many consulting dollars to make a specific program that is compliant with such an API accessible to its users.  I also agree that a truly rich API will increase the kind of competition among AT vendors that will benefit users by a healthy amount.  I also agree that such an API will also make it possible for new and smaller players to succeed in the tight AT marketplace.

I disagree, though, that the breaking of ranks among the AT vendors (see my earlier post on competition or yesterday’s post on Peter’s blog) didn’t largely give mainstream software vendors a free pass to providing substandard accessibility solutions while claiming 508 compliance in their VPAT.  Specifically, the break in ranks among the vision related AT companies caused chaos among the mainstream vendors in their decision to adopt a standard API or not.  GW Micro argued that MSAA provided enough and pushed mainstream vendors to use it, Freedom Scientific quite publicly took a nearly anti-MSAA stance (due to the inadequacies of the API) and promoted the exposure of information through a document object model (DOM), like that in the MS Office suite of products, Corel Office products and Firefox.  FS promoted the DOM described by the WC3 Web Accessibility Initiative (W3C/WAI) as the solution to Internet accessibility.  While DOM solutions require a lot of customization to support each application, they also provide a profoundly large amount of information about the data being exposed.  Recently, Serotek, in Freedom Box System Access and GW Micro in more recent Window-Eyes releases have adopted support for the DOM concept in their versions of internet and Microsoft Word Access and both have received acclaim from their users for doing so.

Taking a pure DOM approach to accessibility does have many faults.  As I state in the previous paragraph, each application may have a different model and to provide contextual information (like the relationship between two random cells in a spreadsheet or the relationship between multiple boxes in an organization chart) will require customization to deliver such information to the user.  Next, as Peter correctly asserts, most application specific object model solutions are also operating system specific.  Thus, an application developer that wants to make their multi-platform solution accessible must do custom work to support Windows, GNU/Linux and Macintosh separately.  

In a perfect world, a cross platform, rich accessibility API would be the ideal solution.  Unfortunately, we do not live in a perfect world.  Returning to the negatively valued competition between the Windows based AT companies, the chaos and historic lack of cross platform compatibility of the accessibility APIs caused many mainstream application developers to choose to do nothing regarding accessibility and place the onus of making applications that do not conform with any standard entirely on the shoulders of AT companies.  Thus, in many cases, only the wealthiest of the AT companies could provide even a passable solution – a reality that only gave benefit to the large application developer who put “screen reader compatibility” on their VPAT.

Furthermore, many application developers, large and small, who only have products on the Windows platforms refused to add MSAA or DOM support because of the enormous cost of retrofitting an accessibility API to tens of millions of lines of source code.  Huge corporations simply said “no” to do anything to their products to promote accessibility.  They refused to add MSAA, they refused to add support for the Java Accessibility API, they refused to add a DOM, they refused to even follow the W3C/WAI guidelines on their web sites and, yes, they refused to hire the relatively tiny AT companies to help them do any of this.

Furthering the argument that AT companies will work around compliance with standards to both improve the experience for their users and to, intentionally or not, give the free pass to the big boys is demonstrated by the back flips and hoop jumping that all credible screen readers do to work around web sites that conform poorly with the W3C/WAI guidelines and the Section 508 standards.  The WAI guidelines have been around for a long enough time to have permeated the consciousness of large corporations.  Web accessibility validation and repair tools have existed for a fairly long time (in software years) so big companies can even automate a large portion of making their sites accessible.  Unfortunately, even with loud complaints from individual users, organizations like NFB and AT companies, compliance with accessibility standards seems nearly impossible to find a place in the minds of corporate web developers.  How then can we expect these same companies to retrofit millions of lines of source code to comply with an accessibility API?  What would motivate these same big corporations to comply with accessibility standards if the vendors of the most popular AT products provide them with techniques to work around their accessibility problems?  Where is the profit motive for a large software vendor to modify their products to comply with an API if they can state that they are compliant with a screen reader and continue to get millions of dollars of contracts from the Federal government?


I cannot speak to either the gnome or Macintosh accessibility efforts until I do some more research.  I do have a GNU/Linux box in my home but it does not run gnome but, rather, uses emacspeak and SpeakUp in text based consoles.  It’s only an old Gateway with 128 mb of RAM and a 450 mhz processor so I think it might choke on a GUI.  I haven’t used a Macintosh in years so I can’t speak to it at all.  

I have, however, been following discussions of UI Automation from Microsoft.  This API is specific to Microsoft platforms but takes an interesting approach by calling itself a component of automated test procedures that just happens to provide benefits for accessibility products.  Linking the accessibility API to an automation layer for test tools is clever and may inspire more developers to use it than would if it only existed for the benefit of people with disabilities.

An open source model for accessibility tools and APIs also provides an interesting approach.  If an open source application provides poor accessibility, one, in theory, can go into the source code and add it.  If an open source API isn’t rich enough to expose detailed contextual information then, ostensibly, it can also be added by a lone hacker, a big company or anything in between as long as they are careful to extend without breaking the standard.  Of course, having individuals and companies make changes to an OS level API will require that an AT user install their peculiar flavor of the accessibility layer and, therefore, could easily break programs from other companies.  Incompatible versions of the Java Accessibility Bridge caused some real headaches which I haven’t kept apprised of and don’t know if they are fixed even today.

So, what is the solution that will bring universal accessibility to computer users with a vast array of disabilities who use a variety of different operating systems for a wide range of different purposes?

In the most far reaching, but likely impossible approach, a “telepathy API” that can live in the OS and through very complex AI heuristics, can determine the context in which the user is working, the specific needs of the user and deliver the information to them using the modality they prefer.  I am sure some of my AI friends would argue that they could probably derive all of this from analyzing the semantic information on a computer’s screen but giants like Chomsky, Minsky and Rod Brooks can’t even start hacking away at this solution.

What given the lack of a utopian solution can we hope for and work towards?  

In this area I agree with Peter entirely.  A highly verbose, extraordinarily flexible and cross platform accessibility API would, if adopted by a large enough segment of the application developers or if smart enough to determine a fair amount of context on its own without any special intervention from application developers, that could be easily made to conform with AT products of all kinds will be the best solution.

How, then, do we convince all of the OS developers, all of the application developers and all of the AT companies to join in working toward such a goal if they can claim 508 compliance with the miserable accessibility in most programs today?  I’m not sure if Peter or I might be smart enough to find this answer.  The history I’ve described above is pretty gloomy and I wish I could share Peter’s optimism that a new API would be the silver bullet we need.  I still contend that, to further the cause of accessibility, we need cooperation, outreach, communication and an end to nickel and dime, “me first” solutions provided by AT companies.