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.
Chris – we’re closer than you suggest. I don’t mean to suggest that “that the breaking of ranks among the AT vendors” didn’t contribute to confusion. But that potential for confusion came from the initial lack of a rich accessibility API from Microsoft (either GWMicro thought MSAA provided more than it did, or felt strategically that they could get enough out of it by pushing it and their relationship to it with mainstream vendors; while Henter-Joyce rightly saw the limits of MSAA). And I agree, if the Access Board were “closer to perfect” (a phrase a colleague of mine likes to use), they would have better spelled out accessibility testing requirements, etc. as you suggested in your ealier post.
Regarding your comparison to HTML and W3C standards, there is a key missing piece: web page creation tools that put the right accessibility stuff in by default. We have the same problem with PDF: you can make it accessible, if you think to do the right things with the right tools; but these are extra, non-default steps you have to take. Contrast this with user interface libraries like Java Swing and GNOME GTK+ and Macintosh Cocoa – use those libraries and your user interface elements expose all the information needed pretty much automatically. MSAA failed because it not only didn’t provide enough information, it also wasn’t on enough of the user interface libraries used to make apps (why didn’t Microsoft put MSAA into MFC at the outset like everyone at their Accessibility Summit in 1995 was pushing them to do?).
We’re starting to explore this question in the OASIS ODF Accessibility subcommittee – how do you help ensure that ODF documents contain all of the needed accessibility information and annotations as they come out of ODF applications (e.g. ALT text on images). As we move to the third generation of accessibility work, I think this question becomes increasingly the central accessibility challenge.
Peter — I agree that you and I are pretty much on the same page. I think that we are viewing the same problem through the lenses of our personal experience (you make accessibility APIs and I used to make screen readers). Thus, we tend to find fault in the things we know best. This morning’s post was not intended to demonstrate how far apart we are but, rather, I wanted to point out that AT companies, along with the Access Board, GSA and nearly useless 508 coordinators are, along with mainstream software vendors, part of the problem in the reality of relatively poor solutions being described as accessible today.
I think that Freedom Scientific, GW Micro and others do an amazingly good job given the circumstances in which they must do their work. I also believe that AT companies would help mainstream developers get their 508 stamp even though their products were software was nearly unusable with a screen reader.
As for authoring tools and document accessibility, I believe that MacroMedia either included a validation tool with DreamWeaver or made one available for free download from their web site. I think Microsoft did something similar with FrontPage as well. The amusing thing about DreamWeaver having an accessibility validation tool is that it wasn’t accessible on its own – blind people could not use DreamWeaver to make their own web sites. Very sad.
I think Peter does raise a valid point about automatic accessibility being offered by standard API’s. One concern I have about asking application vendors to build accessibility into their software is that they have little motivation to do this. Accessibility is not going to fundamentally change the financial success of an organsiation, largely due to it not providing a significant amount of new customers. There isn’t the peer pressure to include accessibility within software as it’s something done by very few companies. All this leads to accessibility only really providing motivation in terms of self-esteem, which was the fourth most significant motivator according to Maslow, which is where the problem lies. Most small and medium companies would likely prefer to invest their development time in features that are either going to secure their existing market share or increase it. This provides greater financial security for that company, and once they’ve gained financial security they’ll likely do what peer pressure dictates.
All this leads to a situation where application developers are highly unlikely to build accessibility into their products unless they have the resources to build in accessibility in addition to implementing features to secure market share and follow peer pressure. It’s likely this lack of motivation that has led to the only application vendors being concerned with accessibility being big companies.
I do think Microsoft, in dual-roling UIA, have made a smart move. Whilst it still requires additional effort to implement UIA on the part of application developers, at least for custom controls, it’s ability to be used in test automation gives more rewards to the application developer than accessibility alone. If J. Stacey Adams is to be believed, then should the rewards outweigh the costs people have the motivation necessary to do things. Whether UIA is more widely implemented than MSAA remains to be seen. I believe it will, certainly in shops that use test automation, and best practice documentation, tutorials and API usability can all be used to help reduce the costs.
One final thought, and that is there is another way. If we can find a way to deliver the visual sensory stimuli in a form other than lightwaves there wouldn’t be a need for any accessibility API’s.