Willie Walker's Weblog

The big topic on my mind right now revolves around the notion of the service based approach to accessibility. I've been working in this space since the early 1990's, having helped create things such as AccessX, the Remote Access Protocol (RAP), and the Java Accessibility API.

I view the work we (Digital Equipment Corporation, Sun, and Georgia Tech) did with RAP as one of the first approaches to a service-based approach to accessibility: we not only just talked about it, we also tried it out. Beth Mynatt, Keith Edwards, and Tom Rodriguez at Georgia Tech also developed Mercator one of the first screen readers based upon this approach. Prior to this work, the majority of the work I had seen in the blind accessibility space involved "screen scraping" and the development of an "off screen model." As a matter of fact, when we formed the Disability Action Committee for X (DACX), I recall members from the Mac and Windows assistive technology communities pushing us to develop an architecture based upon hooks to support screen scraping. We had the luxury of being young and naive, so we chose to continue down the path of the green pasture we had chosen to sow.

So...here we are, around 15 years since we kicked off DACX. The basic model remains the same: an assistive technology gains access to the object model of the user interface for application, interacts with that object model and listens for events from the model. The assistive technology then uses this to provide more compelling access to the computer. Simple. There are several approaches to this model, and these approaches are now available on most graphical platforms. That's good stuff. There's also a number of proof of concepts that this technique can work, and we're seeing this first hand with the GNOME Accessibility Project, which has pushed this model pretty far.

I've learned a lot since the time we did RAP. Much of what I learned is the result of actually working with my wonderful team on an assistive technology: Orca. Prior to that, I was in the ivory tower of the service provider (i.e., the application and/or the toolkit) and not in the land of the consumer (i.e., the assistive technology). Having been in the trenches with Orca for the past few years, and actually -- get this -- working directly with end users (what a concept!) has really made me aware of many things. These include the following:

• The service based model can work and it can work well. We're succeeding with Orca.
• The service based model is not without flaws (I'll discuss these more later).
• We need to let the user experience drive the architecture, and not the other way around. For the most part, the model in place tends to support this. Phew.

Now, why is this a topic on the forefront of my mind? Well, I've been following discussions about why existing API's aren't good for the new (or other) guy on the block, so rewriting the same API to do the same thing becomes necessary. The common reasons are that the languages used to express the interface to the model (e.g., IDL, Java, C, whatever) and the mechanism used to communicate the information (CORBA/IIOP, RMI, DBUS, COM, whatever) have their supporters and detractors. We end up with a number of interesting solutions, all of which are basically the same approach to doing the same thing if you look at it from a 10,000 meter view: an assistive technology gains access to the object model of the user interface of an application, interacts with that object model and listens for events from the model. The assistive technology then uses this to provide more compelling access to the computer. Simple. Oh yeah, I already said that.

So...I ride my bike and I think and I read. I also look at other models solving similar problems, whether they are related to accessibility or not. I talk with end users. I talk with other assistive technology providers. I talk with toolkit and application developers. I ask myself questions. What is the impact of multiple solutions to the same problem? Can this be improved? If so, how can this be improved? Should we try to improve it? What is the impact of trying to improve it? What different kinds of models might be better?

The real fact of the matter is that I have already formed an opinion -- some of it is leaking through in this post. My goal for this blog is to keep myself honest. Write down what I'm learning. Formulate an argument based upon fact. Understand the scope of the problem. Understand the impact of opening my big mouth.

I might surprise myself and my opinion might change. Maybe you (whatever readers I might have -- maybe it's just me -- I don't know) can help me.

For upcoming posts, I hope to talk about the things I know very well (RAP, Java accessibility, AT-SPI). I also hope to talk about areas I've explored directly related to accessibility (Microsoft and Apple's approaches), and other applications/toolkits that expose their user interface or data model for reasons other than accessibility (Firefox, OpenOffice, etc.). It's all good fun.