DACX Chair
Trace R&D Center
As an outcome of this meeting, individuals from several competing workstation manufacturers and assistive technology developers decided to initiate joint efforts towards common accessibility solutions for the X Window System. This meeting also marked the beginning of a long term and on-going advocacy campaign to educate people on the importance of providing access solutions in the workstation market.
Members of this voluntary group began to refer to themselves as the Disability Action Committee for X (e.g., DACX). Dividing into two main groups and communicating mostly through electronic mail, DACX members chose initially to concentrate on visual and mobility access needs for the X Window System.
The mobility access group chose to parallel efforts already available on the Macintosh(TM), DOS, and Windows(TM) platform in the form of Easy Access(TM), AccessDOS(TM) , and the Windows Access Pack(TM) respectively, while the visual access group chose to continue parallel efforts and simultaneously support the Mercator Project, research work in progress, at the Georgia Institute of Technology, Graphics, Visualization and Usability Center.
The remainder of this article contains a brief disability awareness perspective and discusses the overall effort of the DACX group, including work in progress.
The 1990 paper "Thirty-Something Million: Should They Be Exceptions?" summarizes statistics regarding the disabled/aging population, looks at situations where simple changes in design with the disabled in mind successfully benefits everyone for little or no cost, and also addresses the much larger economic cost of not providing accessible designs [Van90]. Perhaps the real challenge and cost for the human factors' community is to build the knowledge and skills base (e.g., researchers, educators, practitioners) and continue to refine our ability to design products with universal access in mind.
The DACX group also discussed features that would allow users to use alternative input devices, as well as features to assist individuals with sensory impairments:
The 1993 paper "Making the X Window System Accessible to People with Disabilities" discusses several of the options investigated to provide the suite of "built-in" access features for the mobility impaired while essentially following the overall goal to modify the X Window System as little as possible [WNTV93]. This was understood to be an important ideal in terms of getting the access features added to the default X Window System and to also allow all users the greatest amount of flexibility.
The DACX group developed an early prototype access implementation using the XTrap Extension in the spring of 1993. The XTrap implementation quickly highlighted the limitations of that approach, while also relying on an extension which is not shipped as a part of every X platform.
After discussions with the developers at the X Consortium, DACX began development on a second implementation that required direct modification (e.g., source code additions and recompile) of the core X Server. This second implementation, called AccessX, included the necessary X Server modifications and user interface X client. AccessX includes StickyKeys, RepeatKeys, SlowKeys, BounceKeys, MouseKeys, and TimeOut. AccessX has been available as part of SUN's Solaris 2.4 and up, as well as Digital UNIX V3.0 and up, and Digital OpenVMS V6.0 and up, operating systems.
Other parallel X development on non-access related issues focused attention on redesigning the X Server keyboard support with the need to improve the support for international keyboards. This redesign led to the development of the X Keyboard (XKB) Extension. The XKB Extension was designed to provide as much backwards compatibility as possible to existing X clients, as well as looking toward the future needs of X, including international needs. XKB also offered the ideal place for installation of the built-in accessibility features which deal with mobility issues.
A prototype version of XKB was completed for release with X11R6 in early 1995. As of November, 1995, DACX members are working with X Consortium members to finalize the library specifications to the XKB Extension, such that it might become a standard with X11R6.1, due in early 1996. The current XKB library specification includes all the above mobility access list features except SerialKeys, which may become part of a different library extension.
With the standardization by the X Consortium on XKB, workstation vendors will no longer be required to change their respective X Servers, and it should no longer be a problem for them to supply the user with the features of AccessX in their default installation/build to assist users with mobility impairments.
For example, when computer screens consisted of ASCII-based command line interfaces, the user input and computer output typically consisted of information on one row at a time. This allowed for screen reading systems to also present the same information to the visually impaired, either in tactile or audio output, one row or line-by-line at a time. GUIs, however, no longer rely on the "80 column by 24 row" or one full screen presentation of information to the user at a time. GUIs have the ability to divide the computer screen into "size-able" regions, typically called "windows", to allow for navigation between windows via an on-screen cursor or relative pointing device, and they contain small pictographs called icons, which can represent various objects in the user's environment. Further, the GUI provides the concept of direct manipulation: for example, via the on-screen pointer, the user may "drag" an object which represents a file to be deleted or destroyed, where-as in the ASCII-based interface, the same action would require the user to type a command. And finally, the designers of GUI are no longer constrained to develop the interface using ASCII characters but are free to create the representation of character, icons, etc., using bit mapped graphics. No longer can screen reading software easily distinguish characters, since it may have to synthesize at a pixel value level exactly what the bit-map on the screen represents [EMS94].
A goal of the Mercator Project, at the Georgia Institute of Technology, is to provide transparent access to existing X-based applications for individuals with visual impairments and blindness. The Mercator methodology behind access to the graphical user interface and not graphical screens is discussed in the 1994 paper, "Providing Access to Graphical User Interfaces - Not Graphical Screens" [EMS94].
Early attempts to provide access to the X Window System during the Mercator Project were based on the assumption that no modification to existing toolkits or X applications were permitted [ER93], [EMR93]. Therefore, the job of gathering information at the X protocol level between the X Server and client(s) was initially done using, in essence, a pseudo-server called the Protocol Interest Manager (PIM) [ER93]. This low level protocol, however, contained almost no semantic information, making it difficult to determine the meaning of the interface while monitoring the interface alone. To offset this problem, the Mercator Project also initially used a modified version of the Editres protocol to gather additional information regarding a client or applications widget hierarchy, including name, class, ID, etc. Combining the higher level semantic information supplied by Editres with the low level X protocol information allowed the early Mercator prototype to get a good picture of what was going on inside an application [EMR93].
While the combined pseudo-server/Editres version of Mercator gave good results, several limitations of the system were also realized [EMR93]. Taking what was learned from the first Mercator prototype, it was determined that a more robust and flexible approach would be to modify the underlying X libraries. Modifying the X libraries addressed several of the shortcomings of the previous approach. Design changes to the Xt Intrinsics and Xlib libraries defined as "hooks" were developed to capture "interesting" changes in the graphical interface [ERM93a]. This was done to satisfy the screen readers need for more high level information about the graphical interface. At the same time, thought was given to the need to send this collected information along a channel independent of the X protocol to the screen reader.
Development began quickly on a second Mercator prototype utilizing the modified X libraries. The Xt hooks were designed and implemented to provide the high-level information about the interface needed by Mercator. An Xlib hook was designed and implemented as sort of a "safety" net, for collecting any X protocol information not trapped with the Xt hooks. For example, rendering large amounts of text to the X server is often undetected by the Xt hooks. Through continued discussions with the X Consortium regarding the Mercator modified X libraries, it quickly became apparent that the proposed Xt/Xlib changes could be used by a number of different X applications (e.g., prototyping tool, profiler, etc.), not just screen readers [EMS94]. As a direct result of this work, a slightly modified version of the Mercator proposed Xt/Xlib "hooks" survived X Consortium review and became part of the standard X libraries with release X11R6 of the X Window System.
As all the information trapped via the Xt/Xlib hooks was collected, development of a channel independent of the X protocol to transport that information to the screen reader quickly became a necessity. This led to the development of the remote access protocol (RAP) [Wal93], [ELMW95]. RAP defines a common language for inter-client communication. RAP includes both the ability for agents to make requests to clients as well as the ability of clients to asynchronously generate a "notification" message to interested agents (e.g., screen readers). RAP protocol and procedures have been under development and discussion in a public forum sponsored by the X Consortium. Anyone interested in contributing to the effort is encouraged to join the list serve by sending a message to <x-agent-request@x.org>; the body of the message should contain the single word "subscribe". Interestingly, the Editres protocol itself has also undergone some enhancements via Bull, France, such that it and RAP may combine into one common protocol [ELMW95].
Now that the Xt/Xlib hooks are part of the X11R6 standard and RAP is under review by the X Consortium, all that remains to be resolved is the initialization of the inter-client communication or rendezvous mechanism [ELMW95]. Once the inter-client communication or rendezvous mechanism is implemented, the screen reader using RAP could communicate with all X applications running on the system prior to starting the screen reader as well as establish communications with all X applications that start after the screen reader is running. Current thinking would suggest the client could install a message event handler within the VendorShell widget class as shipped by the Consortium. The client would be required to maintain a protocol name table which would also require a handful of routines be added to Xt or Xmu libraries to manage the installation and "jump-starting" RAP [ELMW95].
While all the Consortium work around Mercator and RAP has been going on, a next version of the Mercator Project screen reader has been in parallel development, making use of the now standard X11R6 hooks in Xt/Xlib and the latest prototype version of RAP. Beta testing with this most recent version of the Mercator Project screen reader is now underway (e.g., fall of 1995) at the National Security Agency (NSA). For clarification purposes, the screen reader version under evaluation at the NSA is being referred to as Sonic X. The Mercator Project staff in conjunction with NSA are finalizing their research, and plans are underway to correct problems and incorporate any new features discovered during the beta test period. If the Sonic X research concept becomes a commercial reality, it will probably have a different name, such as "UltraSonix".
Several accessibility issues remain to be addressed, however, when accessing a computer workstation or some of the newly appearing electronic information systems (e.g., information kiosks, touch screen telephones, etc.). It is hoped that the enthusiasm of the DACX members will excite others within their respective organizations to further carry the concepts of "design for everyone" to the next level.
For additional information regarding DACX, The Mercator Project, or RAP, you can look at the following internet sites:
For additional information regarding Trace R&D Center, contact:
Trace R&D Center
University of WI-Madison
1500 Highland Avenue
Madison, WI, 53705-2280
[ER93] W.K. Edwards, and T. Rodriguez, "Runtime Translation of X Interfaces to Support Visually-Impaired Users." The X Resource, A Practical Journal of the X Window System, Proceedings of the 7th Annual X Technical Conference, pp. 229-238, January, 1993.
[ERM93a] W.K. Edwards, T. Rodriguez, and E.D. Mynatt, "Mercator Xt-Based Protocol Specification", Draft, March 1993.
[EMR93] W.K. Edwards, E.D. Mynatt, and T. Rodriguez, "The Mercator Project: A Nonvisual Interface to the X Window System." The X Resource, A Practical Journal of the X Window System, pp. 33-53. Issue 7, Summer 1993
[EMS94] W.K. Edwards, E.D. Mynatt, and K. Stockton, "Providing Access to Graphical User Interfaces - Not Graphical Screens." Proceedings for the ASSETS '94, the First Annual International ACM/SIGCAPH Conference on Assistive Technologies, November 1994.
[ELMW95] W.K. Edwards, E.D. Mynatt, S.H. Liebeskind, and W.D. Walker, "A Remote Access Protocol for the X Window System." Unpublished Report Submitted to: The X Resource and the 9th Annual X Technical Conference, December 1995.
[KS89] L. E. Kraus, S. Stoddard, "Chartbook on disability in the United States: An InfoUse report." Washington, DC: U.S. Department of Education, National Institute on Disability and Rehabilitation Research, 1989.
[Van90] G.C. Vanderheiden. "Thirty-Something Million: Should They Be Exceptions?" Human Factors, 32(4), pp. 383-396, 1990.
[WNTV93] W.D. Walker, M.E. Novak, H.R. Tumblin, and G.C. Vanderheiden. "Making the X Window System Accessible to People with Disabilities." The X Resource, A Practical Journal of the X Window System, Proceedings of the 7th Annual X Technical Conference, pp. 213-227, January, 1993.
[Wal93] W.D. Walker. "Remote Access Protocol (RAP), Version 0.2." DACX Work in Progress. November, 1993.
1 For purposes of this paper, workstation refers to computers which use an operating system that is both multi-user and multi-tasking, typically a combination of UNIX and the X Window System.
2 There are parallel efforts underway at several sites around the world to provide access to the X Window System for the visually impaired. However, this paper concentrates only the Mercator project and its progress.