Willie Walker's Weblog

Back in January 1993, Mark Novak, Dr. Gregg Vanderheiden, Henry Tumblin, and I published a paper based upon our previous year or so's worth of work looking at Making the X Window System Accessible to People with Disabilities. At the same time, Keith Edwards, Tom Rodriguez, and Beth Mynatt from Georgia Tech were collaborating with Earl Johnson at Sun on the early aspects of the Mercator screen reader. We joined forces that year to implement ideas we had all been talking about, the main one being a service-based approach to assistive technologies.

To support Mercator, we created the "Remote Access Protocol" (RAP - see A Remote Access Protocol for the X Window System), which was loosely based upon the Editres protocol (see Kenton Lee's article on Chris Peterson's Editres work). RAP, however, was designed specifically with assistive technologies and better performance in mind.

The main ideas behind RAP are pretty much identical to what we see in today's modern approaches: RAP hooks inside the GUI application/toolkit, exposes the widget hierarchy of the application to external agents, and provides a means for the external agent to query/modify object attributes. It also provides a means for notifying the external agent about changes to the hierarchy and changes to widget attributes. The external agent we used to prove this was the Mercator screen reader.

The other main idea behind RAP was to support the rendezvous between the GUI clients and the external agents. For this, we created An ICE Rendezvous Mechanism for X Window System Clients, which is described in Appendix B of The Inter-Client Exchange Protocol.

So...why isn't RAP used today?

Many reasons.

• People decided the Xt-intrinsics were bad, so they invented their own ways to create toolkits that were just as bad, but at least they wrote it, so it must be good (how many times do people have to rewrite the push button widget?!?).
• Companies and individuals rebelled against the licensing of the more popular Xt-based toolkit at the time, which was Motif. Remember Lesstif? Oh wait, that still exists? Wow.
• People decided they could do a better job of interprocess communication (and some actually ended up doing better job).
• Companies, such as the one I worked for, began disinvesting in the desktop; access to X was among the first to go. That was OK by me -- Earl Johnson at Sun was recruiting me to apply RAP concepts to this thing called Java. The curious innards of the AS/U code just were not enough to keep me at DEC.

So...what was good about RAP?

The combined RAP/ICEXRendezvous/Mercator solution was one of the first on any platform (definitely the first on X) to show that a service based approach to accessibility could be made to work. It was good seminal work in the space and I'm lucky to have been part of it. Everyone involved was also just plain great to work with.

RAP was also very extensible -- it was just a remote conduit into Xt, and would naturally (and without modification) pick up any new Xt widget that came along in a toolkit.

So...what was bad about RAP?

In retrospect, RAP was too tightly bound to the X platform and the Xt widget set. Marty Geier at the MITRE Corporation carried the RAP torch for a while to help with his distanced collaboration work. I'm afraid the writing was on the wall for Motif, however, and Motif just quietly died a lonely death, taking RAP with it.

Another thing difficult about RAP is that its object model and event model were dictated by the graphical toolkit. Graphical toolkits are notorious for their incomplete specifications. IMO, developing apps from graphical toolkits has always been one of coding by [poor] example and/or suck-it-and-see-what-happens. It's unfortunate, but I think it's just the nature of dealing with such a large variety of widgets with a large variety of attributes that can all be set and combined in almost every way.

The result of an incomplete and ambiguous spec is that, while something like RAP could be toolkit independent, the assistive technology still needs have to have a priori knowledge of the toolkit it is working with. The assistive technology's job becomes more difficult the more toolkits there are.

A holy grail for us is that the assistive technology need not know what toolkit it is dealing with. After all, just how many different ways are there to really express what a push button is? To achieve this holy grail would mean being very specific about the object and event models to be exposed by RAP.

For examples of what needs to be be specified, take page tabs and their panels. Is there a parent/child relation between the tab and the panel? Are they really one object? Are they handled in parallel lists (one list for the tabs, one list for the panels)? In addition, what events are possible and (perhaps more importantly) what is their order and (perhaps most importantly) what user action caused a particular set of events?

Defining such a tight specification would have caused the accessibility haters of the time to hate us even more, and we never would have received clearance for take off. This access by [ambiguous] contract is still a concern in today's modern and improved world.

Finally, the whole approach we chose for looking at the GUI model instead of the application data/task model might be something to think about. After all, the GUI really is just a window onto the data/task model. When I first started in the accessibility field, my thinking was that the data/task model was most important. Expose the data/task model and you write any interface for it that you want. Brilliant, or so I thought.

The data/task model idea led me down the path of reading about UIMS systems from the 1970's. The fact that it had not been solved by the 1990's was a matter of concern.

In addition, I also learned the idea was very unpopular among people with disabilities. The primary objection was that this would just encourage people to make inaccessible interfaces: the accessible interface to each and every application would be deferred to the mythical army of accessibility developers out there. Can you spell "fat chance"?

Finally, I was also reminded that people with disabilities aren't an isolated community. They are educators, collaborators, co-workers and friends of people without disabilities. As a result, they need to access to the same interfaces used by everyone else.

Well..that about wraps up RAP. I left my job at Digital to abandon X, abandon the C programming language, head to Sun to see what this Java thing was all about, and then work to make Java accessible. My next entry will be about the accessibility work we did with Java.