(This is a working paper of the Trace R&D Center. This paper supercedes the preliminary work presented at the 1996 RESNA Conference as a poster session. We will be continuing to update this document as work in this area evolves.)
Table of Contents:
Public information systems and appliances are increasingly being designed to include features which allow them to be used directly by people with disabilities. However, we do not know at present how to design such systems so that they can be accessed by everyone, especially those with severe or multiple disabilities where use of a personal assistive device might be required.
One mechanism for allowing these individuals to access public information appliances would be to include a low-cost infrared link as a part of the devices' design. Users could then interface with the device using their own interface, or on their personal assistive technology. For example:
The Universal Auxiliary Interface (UAI) Protocol is intended to be used with a number of electronic appliances that have already begun to appear in the market place. In most cases, the protocol would be used over an infrared link such as the IrDA. Examples of electronic products that the UAI Protocol might be used with include:
The protocol, used in conjunction with a low-cost infrared link, will provide a simple, rugged, low-cost and flexible mechanism for supporting a wide range of auxiliary input interfaces with these products.
The goal is to develop an auxiliary interface protocol "standard"
suitable for use over infrared and other communication links which
would allow auxiliary input and display interfaces to be used
in lieu of the built-in interfaces on a wide variety of mainstream
electronic products.
A major purpose of this protocol would be to allow interfaces
which are quite different from the interface used on the product
to be used to access and use the product. For example, a product
which uses a touchpad and LCD display could be controlled by an
auxiliary interface device which had only a speaker for output
and a microphone and voice recognition for input. It could also
be controlled by a device which had only a dynamic braille display
for output and an alphanumeric keyboard for input. In order to
achieve these goals, a protocol is needed which will allow an
auxiliary interface device to easily and efficiently secure, display,
and control information from a DEVICE in a text format that can
be easily displayed in any desired modality (auditorially, visually,
tactually, etc.). The system should allow the auxiliary input
device to secure and display any important information needed
for operation of the device, and should provide a means of operating
all controls needed for operation of the device.
The overall objective of this project is to develop an industry standard for allowing assistive technologies or other auxiliary interfaces to connect via an infrared link with standard devices. Some specific objectives include:
The Trace Center, as part of the Electronic Curbcuts Program, in cooperation with CSLI, Stanford, and others internationally, have initiated a project to investigate the use of infrared technology as a means for individuals with disabilities to access electronic information systems.
A series of meetings which coincided with major disability related conferences have been held to gather input, ideas, and feedback from researchers, developers, consumers, etc., regarding the implementation and usage of infrared technology to access electronic information systems. The first such meeting was held in conjunction with the California State University Northridge (CSUN) Conference in March, 1995. Similar meetings have been held at RESNA '95, Closing the Gap '95, CSUN '96, and RESNA '96. As an outcome of these meetings, and communication via the listserve and email, a UAI Protocol with the following objectives and requirements was defined (see below). From these, requirements and a draft protocol were proposed. Subsequently, a prototype system was created; the protocol has been refined based on experience in implementing this prototype.
In addition:
At the present time, the overall desired connection is seen as consisting of three basic components.
(Item #3 would then define the information which must be supplied by the standard device and would also define the type and format of the information which would be received by the auxiliary interface.
Any connection mechanism can be used for this stage. An RS232 serial connection, for example, would meet the requirements, as would a parallel connection.
In order to provide a low-cost, robust, vandal-resistant and flexible interface, however, an infrared or other wireless link is proposed. Further, the use of the standard infrared link being promulgated by the IrDA (Infrared Data Association) is recommended. Various different but compatible infrared links are being proposed by IrDA to meet the different requirements of consumer and high-speed data equipment. Since the data demands for this application are not high, the recommended standard would be the one with the best range and angle of view to reduce the amount of positioning necessary on the part of the auxiliary input in order to work successfully.
In applications such as control of home or office appliances, the security component may not be necessary, and may be omitted. However, in other interactions and transactions, the user may want to maintain secure communications between the auxiliary interface and the standard device. Examples include ATMs or other activities including the transfer of money, or personal and private information.
At this time, we have not established any standards in this area. Perhaps a standard will evolve out of the other IrDA work. We have discussed strategies involving the exchange of public keys in a two-key encryption scheme, with the auxiliary interface first providing a key and then the standard device providing a decryption key in encrypted form.
The third component would be the communication protocol: what the auxiliary interface and the standard device would use to communicate with each other. The proposed protocol is termed the "Universal Auxiliary Input Protocol" or the "UAI Protocol."
Our objective in creating the protocol was to create something which was as simple as possible and which would place minimum demands on the standard devices. This was done to enhance the adoption and implementation of the protocol by industry.
We also recognize that the nature of interfaces may change over time. As a result, the protocol allows for extensions at a later date as needed in order to support very different interface technologies which may emerge.
The current protocol consists of just four commands which can be sent from an auxiliary interface to a standard device, and two spontaneous messages which are sent from the standard device back to the auxiliary interface.
The four commands are:
The spontaneous messages (e.g., messages not sent in response to a request from the auxiliary interface) are:
Each of these is explained briefly below. A technical description for the commands as well as their data formats are presented at the end of this paper, in the section "Technical Format for the Transmission Protocol."
This command simply causes the standard device to go back into a state which would be equivalent to it just having been turned on. The purpose of this command is to allow someone who comes up to a kiosk, ATM, or even an appliance where the device has been left in an unusual state by the previous user to reset the device into a known start-up condition.
This command causes the standard device to send to the auxiliary interface a listing of all of the pieces of information or commands (buttons, etc.) which are available to the user on the standard device. This listing includes all of the fields, the labels, the text, and other information displayed on the screen, as well as any buttons, controls, or commands which can be issued by a user. Because all of the information presented visually or auditorially by the system would be available in this list, the user would not have to be able to see or hear the standard device in order to have access to all of the information being presented by the device. Because all of the commands and controls would also be available in this list, the individual would not have to be able to touch or reach the standard device in order to completely operate it.
The "activate" command is used by the auxiliary interface
to activate any of the commands in the list, or to request the
content of any of the information items in the list.
For example, the "activate" command could be used to
push any button on a touchscreen, or to activate any control.
It can also be used to ask for the contents of any block of text
or other information item on the screen.
Whenever an "activate" command is issued, the standard device echoes an aknowledgement of the command activated (or sends an error message if a nonexistent command is attempted.)
If the command causes the device to be busy for a period of time, the device would issue a "One moment" message. When the device finished being busy, it would respond with a comment indicating its current status.
Any time that the listing of current commands and information changed (whether because of a command issued by the user or for any other reason), a "List changed" message would be sent to the auxiliary interface. The usual response of the auxiliary interface to this message is to immediately request a new list, as discussed under "List" above.
Depending upon the device, there may be some special settings which pertain to the use of the auxiliary interface link. If this is so, sending the settings command would result in a list of the setting options.
For example, it might be possible to turn off the standard user interface when the auxiliary interface was being used, for either security or privacy reasons. The user may want to turn off the standard controls but keep the display a tive, or turn off the display, or both.
Another option might include a change in the behavior of the standard user interface to enhance its use in conjunction with the auxiliary interface. For example, items might be highlighted on screen as they were activated.
You are welcome to join the infrared list serve discussion by
sending email to:
do not put a heading or signature in your email
in the body of your message type:
(if your name is Robinson Crusoe; if not, substitute your own name)
This document and other information on this topic is available at Designing an Accessible World in "Infrared and Other Interface Standards" at http://trace.wisc.edu/world/irstds.html.
THERE ARE FOUR COMMANDS THAT CAN BE SENT BY AN AUXILIARY INPUT:
Two basic commands:
Two set-up commands:
NOTE: When the user sends the "list" command (#L), the "information device" (e.g., kiosk) may (at its own option) display the names or reference numbers next to the items on the screen. This would be done to facilitate access by users who can see the screen but who must use an alternate device connected via the IR link to activate the buttons on the screen (e.g., someone using a sip-and-puff keyboard to activate a kiosk).
All information sent by the "information device" is in response to commands from the user ("auxiliary interface") or to notify the user of a change in context.
NOTE 1: When replying to an AUXILIARY INTERFACE, a carriage return is not transmitted by the INFORMATION DEVICE, so that the response could appear on the same line of the user's display (although the device could also choose to display each message on a separate line).
NOTE 2: All messages sent by the INFORMATION DEVICE should be
terminated with an END OF TRANSMISSION (EOT) (control-d) (hex
004) character.
FORMAT OF TAB-DELIMITED "LISTING" TABLE
EXAMPLE OF THE TAB-DELIMITED TABLE SENT IN RESPONSE TO "LIST"
<SOH>L1<tab>Name Of Context<tab>1<ret>
#1<tab>Description and Help<tab>(blank)<tab>(blank)<tab>"invisible
located at 0,50,0,30 of 0,0,480,640<ret>
#2<tab>(name of button)<tab>button<tab>(blank)<ret>
#3<tab>(another button)<tab>button<tab><tab><ret>
#4<tab>(name of text)<tab>text block<tab><tab><ret>
#5<tab>(name of field)<tab>scrolling field<tab><tab><ret>
#6<tab>(name of button)<tab>check box<tab>true<tab><ret>
<EOT>