Mark Urban & Bill LaPlant INCITS/V2 incits/tc_home/v2

Auxiliary Interface Access Protocols (AIAP) for Assistive Technology:

Controlling Next Generation Technologies from Assistive Technologies

Mark Urban & Bill LaPlant

INCITS/V2

www.incits.org/tc_home/v2

Adapted from original material by Gregg Vanderheiden

The Problem

People are faced with a product– they cannot operate

– in a place where they cannot adapt or modify the product to meet their needs

– Kiosk, ATM, Copier, TV or device in Hotel Room

People with disabilities cannot get the needed efficiency through the interface that is built into the product– e.g. Workstation

Approach 1 - Build access into the product

Natural Access Doesn’t require user to use “special device”

– Especially nice for older people

– Most cost effective way for all ages

Often not possible commercially to build in access for all disabilities - especially severe/multiple disabilities that require special hardware

• Deaf blind (braille)

• High spinal chord injury (interface attached to user)

• Severe Cerebral Palsy (large / spaced controls)

Sometimes cannot provide needed efficiency for workstation like applications, even for less severe disabilities

Approach 2 –

Provide User with a Means to Change the Interface

By either a) allowing them to control the product through a

different interface device ORb) allowing them to download information or code to

the device to change its interface

The focus of the V2 group is to develop standards to support Approach 2 (option a or b) for those who need it

What is V2? What is AIAP?

V2 is a technical group of National Center for Information Technology Standards (NCITS) ..– an industry consensus standards group

that is working on AIAP

AIAP stands for Alternate (User) Interface Access Protocol. – It is a general name we are using for this work– There actually isn't just one protocol or standard and

the name is not official – just a handle we were using.– Probably better to think of this work just as the V2

standards work

V2 Working Group Objective

The purpose of the V2 is – to provide standard mechanisms – for people (including those who have disabilities) – to be able to change the user interface on

standard mass market (target) products – to an alternate user interface that they can operate

or operate more easily

V2 is exploring 4 different ways to allow the user to change the interface

1. Allow the user to substitute an equivalent hardware interface component

e.g. alt keyboard, mouse, display

2. Allow the user to operate the product using a different device (remote console)

e.g. assistive technology

3. Allow the user to download user characteristics or preferences which would change the interface on the product

4. Allow the user to load new interface software into the product

#1 - Person cannot use interface on product –

Interface HardwareInterface Software Function Software

#1 - Person cannot use interface on product – But has alternate keyboard they can use


#1 - Person cannot use interface on product – But has alternate keyboard they can use

V2- Effort #1 is aimed at giving them a way to use it instead of the keyboard on the product


#2 - Person cannot use interface on product – but has alternate interface device (like a Braille Lite, Braille Note, or Aug Com Device etc.)


#2 - Person cannot use interface on product – but has alternate interface device (like a Braille Lite, Braille Note, or Aug Com Device etc.)

V2- Effort # 2 is aimed at giving them a way to use it instead of the entire interface on the product(“Alternate Console”)


#3 - Person cannot use interface on product – but has a card or device that describes their abilities OR their preferences.


#3 - Person cannot use interface on product – but has a card or device that describes their abilities OR their preferences.

V2- Effort # 3 is aimed at giving them a way to send their information to the product – so that the product can adapt its interface to meet their needs



.


#4 - Person cannot use interface on product –but they could if new interface software could be located or created for them and loaded into the product.


#4 - Person cannot use interface on product –but they could if new interface software could be located or created for them and loaded into the product.

V2 – Effort #4 is aimed at providing ways for alternate software to be called up and downloaded into a product to replace some or all of the standard software.


Implications for Assistive Technology Vendors

Sec 255 cites support for a standard like this Sec 508 cites compatibility with Assistive

Technologies Industry is asking for standard approaches to

compatibility with AT If this is implemented, then that AT which

supports it will have access to a wide range of technologies

It is important that AT constraints and issues be reflected in the standard.

Some AT Issues

Will the standard be backward compatible– Will it work on old AT or only on new AT– Will the standard be designed in a way that would

allow old AT to use an adapter? Or not.

What will the costs for including this standard in AT be?

What benefits would there be within a product line.

AT Manufactures’ Participation

It is essential that AT manufacturers participate in the process– To make sure their interests are reflected

– To make sure that the standards will be compatible with manufacturing techniques and technology used by AT manufacturers

– To address backward compatibility issues

– To gain their expertise in meeting the needs of people with disabilities who use AT

Thank you

Current Requirements for Effort #2 Remote Console Standard (Draft)(1) The standard must require

(1) that the target device provide all information that the target device usually presents visually or auditorially to the remote console via the protocol in human comprehensible electronic text (e.g. Unicode).– [If content is not inherently translatable into text this is out of scope (e.g. GIS, Music, Data Mining, force feedback, etc.)?]

(2) The standard must require the target device to present all functions that the target device is capable of performing to the remote console via the protocol in human comprehensible text (e.g. Unicode) and that the command back to the target device be transmittable in human comprehensible characters (e.g. Unicode). (For example, pick from list and send a code for list item or list item number back.)

(3) Application controlled timed events (e.g., time outs, response requirements, etc.) must be (1 or more of the following options): (a)[GZ4] able to be turned off (no time dependent responses), or (b) adjustable by the user to five times the default response time (or presentation time), or (c) provide a warning of a time out and allow at least five (10?) seconds for the user to respond. [Note: This requirement is separate from real (non-application controllable) event timing. For example, driving a car requires that an individual be able to respond within a certain period of time in order to keep the car on the road.] (4)[GZ5] The standard must not require connection to the Internet. (5) The standard must not require that the remote console have any prior knowledge of the target device including any knowledge of its commands, command structure, language, type, etc., beyond those specified by the protocol. (6) The standard shall be applicable in a limited bandwidth environment. (7)[GZ6] The standard must be compatible with an underlying network protocol which is able to poll and scan the environment and allow the user to present and select a desired target for interaction. This includes support for communication with multiple targets. (8) The target device[GZ7]’s information and control items shall be representable in a linear manner (e.g. unique numbers).

(8a) If information and control items are (e.g. hierarchically, tabular) grouped the standard shall support the transmission of the grouping to the remote console. (9) In addition to the linear presentation the standard shall allow transmission of additional information to facilitate the remote console's presenting the information and control items in non-linear, or non-text forms (e.g. graphical button on a LCD touch screen). (10) The standard needs to be able to communicate asynchronous changes (about the target device's status) from the target device to the remote console. [Note: Should we allow asynchronous status messages in both directions?] (11) The standard shall establish and maintain the certainty of connection with a single (or multiple) remote console(s) so that the target device can determine when the remote console(s) depart(s). [Note: "ping"[GZ8] feature: is there any other status information that the target device needs to know from the remote console?] (12)[GZ9] The standard must specify what the target device does with reset command and with remote console disconnect event (this is necessary for user expectation). The target device must notify the remote console when reset complete. (13) [GZ10]The standard must support security and privacy features: - at least as secure and at least as private as the default target user interface. (15) The standard shall support multiple natural languages. [Note: The protocol shall provide support for: - conveying information in different languages, - identifying the language to the remote console, and - letting the user choose a language.] (16) [GZ11]The standard supports having an remote console which lets the user group controls from different target devices into a single user-constructed menu on the remote console. [Note: This could be achieved by the atomic protocol requirements: - Unique device ID, and - stable (unique) command ID (only for non-context sensitive commands). (17) The standard shall support optional help text for the information and control items. [Note: This could be by query on the part of the remote console, or as part of the menu list.] (18) The standard shall require the target device and remote console to identify themselves (including product manufacturer and version?). Other Considerations (i) Cheap remote console devices. (ii) Scalability of presentation modes (e.g. scalable graphics). (iii) Voice input should be one practicable mode for controlling the remote console. (iv) Support animated and interactive objects for representing and making choices. (v) Support the use of AI / heuristics in the remote console to figure out the meaning of “incomplete” commands. * (vi) Standard should support the ability to communicate graphics and other non-text presentations. Able to define media fragments as functionally equivalent and hence alternatives one for another. (vii) The protocol should be extensible (support future functionality and features). [Note: e.g. version identification and backward compatibility.] [GZ1]Do we want to distinguish special cases where the data is generated by the application or by the user (e.g. picture in Word)? [GV: Not sure what you mean. Either way the content would exist and need to be fed back to the user on request] [GZ2]Distinguish the stability of the user’s control of the process from completeness of coverage of the functions and from completeness of information. [ This really needs to be translated into easier to understand language] [GZ3]Facilitates programming in AT and facilitates debugging by having the character string printable. [GZ4]See also UAAG-1.0. [GZ5]An implementation might require the Internet, but the standard does not. [GZ6]Discussion needed about level of implementation (Al). [GZ7]Replace target device with target product? [GZ8]“Heartbeat” [GZ9]Do we require a reset command (in what states?)? Asynchronous or synchronous? [GZ10]Is this too strict? Is it always possible to have as much security? [GZ11]AG: Hard to do.

There are 4 ways that AIAP is currently envisioned to provide a means for users to change the user interface.

By using an alternate user interface component instead of the native user interface component.

By allowing a person to use a complete alternate user interface (including alternate input, control and display devices) instead of the native input, control and display devices on the product.

By allowing the user to cause their characteristics or user interface preferences to be communicated to the target product (either directly or by providing a code which the device uses to look up the user preference or characteristics) where the target product changes its own user interface behavior based on the user preferences or characteristics (no new software communicated to target product).

By allowing the user to cause new user interface software to be determined and downloaded onto the target device directly or indirectly.

Mark Urban & Bill LaPlant INCITS/V2 incits/tc_home/v2

Documents

Transcript of Mark Urban & Bill LaPlant INCITS/V2 incits/tc_home/v2