Universal Auxiliary Interface 
Protocol (UAI Protocol)

A Protocol for Communication Between a Device and an Auxiliary Interface
(suitable for use over infrared and other communication channels)

Working Paper

Revised 7/15/96

(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:

  1. Problem Statement
  2. Need for a Standard Protocol
  3. Goal and Objectives of the UAI Protocol Effort
  4. Status of the Effort
  5. Requirements Identified
  6. Overview of the Protocol
  7. How You Can Participate
  8. Other Information
  9. Draft Protocol

    1. PART I: Protocol for communication from the "auxiliary input" to the "information device"
    2. PART II: Protocol for communication from the "information device" to the "auxiliary interface"


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:

Need for a Standard 

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.

Goal and 
Objectives of the UAI Protocol Effort

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:

Status of the 

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:


Overview of the 

At the present time, the overall desired connection is seen as consisting of three basic components.

  1. a hardware/software protocol for establishing a physical infrared connection between the auxiliary interface and the standard device.
  2. a protocol for establishing secure communications over this physical link (when security is required).
  3. the establishment of a communication protocol for securing information from and transmitting commands to the standard device.

(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.

1. Hardware/Software Link

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.

2. Security

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.

3. Communication Protocol

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:

  1. Reset
  2. List
  3. Activate
  4. Settings

The spontaneous messages (e.g., messages not sent in response to a request from the auxiliary interface) are:

  1. "One moment"
  2. "List changed"

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.

How You Can 

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.

Draft Protocol

July 1996

PART I: Protocol for 
communication from the "auxiliary input" to the "information device"


Two basic commands:

  1. LIST
    Function: Send a list of information and action items
    Form: #L<ret>

    Function: Activate given item
    Form: #item reference number<ret>
    "verbal name of item"<ret>
    main menu<ret>

Two set-up commands:

  1. RESET
    Function: Reset system to start-up
    Form: #R<ret>

    Function: Send a list of the setting options
    Form: #S<ret>

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).

PART II: Protocol for 
communication from the "information device" to the "auxiliary interface"

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.

  1. In response to LIST, the DEVICE sends a tab delimited table listing all items (information items, action items or commands) in the current context (that is, items which are currently available for reading or action). (See below for details on format for this tab-delimited table.)

  2. In response to ACTIVATE, the DEVICE would echo the verbal name of the item which was activated.

  3. In response to RESET, the DEVICE sends "RESETTING NOW" when the reset command is received. When it is done resetting, it sends a status message indicating the context (for example, "Idle Screen" or "Main Menu").

  4. In response to the SETTINGS command, the DEVICE goes to an auxiliary interface settings screen (context), and sends the "List changed" message. The user can then issue a "LIST" command or type in a string to directly activate a setting. Typical settings available through this mechanism would be "blank screen," and "mute speaker." (When a user approaches the kiosk, they might just send a string of commands which would reset the kiosk and turn off the screen and sound and then return to the main menu.)

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.



<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>