[Accessibility] For today's call: Sec2b

Janina Sajka janina at rednote.net
Wed Sep 10 10:47:14 PDT 2003


1.)AT-SPI (Year One)

The Assistive Technology Service Provider Interface (AT-SPI) was developed for the GNOME2 desktop and its approach to providing accessibility is in the
process of being adopted by KDE.

AT-SPI is toolkit-neutral. It is already compatible with and supported by GTK+ 2, Java/Swing, the Mozilla suite, and StarOffice/OpenOffice.  Support via
reuse of the related ATK interface in version 4 of KDE's Qt toolkit has been announced by TrollTech.

AT-SPI enables assistive technology tools, e.g. screen readers, magnifiers, and even scripting interfaces to query and interact with graphical user
interface (GUI) controls." As such it facilitates access for individuals who cannot use the standard GUI. It enables developers (or a third party) to
build applications that are, or can be made accessible. The AT-SPI enables developers and distributions to meet the accessibility requirements of many
individual and corporate customers.

AT-SPI is an existing mature API that we propose to adopt.

2.) AT Device Shared I/O (Year One)

AT device shared I/O would make it possible for devices that are commonly used by persons with disabilities to operate smoothly with several client
applications simultaneously.

In some circumstances it is necessary to support simultaneous access for different client applications. For example, allowing a software-based speech
synthesizer to speak while a multi-media stream is playing, rather than queueing its messages to play after the stream concludes. In addition, it may
also be necessary to have messages queue or supress until a particular window or console has focus.

We need to adopt or develop libraries that allow client applications to share these I/O devices. Shared access to accessibility related devices, such as
Braille displays, reduces the cost of ownership and improves the user experience.

These libraries should offer a generic high-level abstraction of the underlying device to allow client applications, and to use the libraries
independent of the actual hardware in use.  This simplifies the development of accessibility related software by sharing commonly used code such as
low-level driver implementations in these libraries.

Two representative candidate libraries/APIs providing this service for braille devices, libbrl and brltty, are already available on the Linux platform.

3.) Keyboard Accessibility (Year One)

Persons unable to use a keyboard and mouse sometimes use alternative devices. However, many users can be accomodated programatically through software
that causes a standard keyboard to behave differently. Many of these features and behaviors have long been available in the XKB specification
 available at
http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps.

One keyboard accessibility feature provided in the XKB specification is sticky keys, which permits users who cannot press key combinations. For example,
the user is unable to press the Ctrl-Alt-TAB keys simultaneously. Sticky keys allow them to achieve the same result by pressing the keys sequentially.

Individuals with mobility impairments will benefit by having such features built-in and available through standard activation strategies, such as
tapping the Shift key five times to activate sticky keys. The routines provided by the API will also benefit assistive technologies such as on screen
keyboard and screen reader applications.

We propose to identify and adopt a subset of the XKB specification in order to provide standard keyboard features and behaviors required by persons with
mobility impairments.

4.)	Text-only accessible booting (Year Two)

It should be possible for any user who is a person with a disability to access any user supported interface during the boot process, including the
selection of the kernel to boot, rescue modes, interactive device loading, etc.  We will develop the best practices and coordinate with kernel and boot
loader development teams to facilitate the interfacing of assistive technologies at any point during the boot process where user access is supported.

This will particularly benefit those users with disabilities who are technology professionals and need, or desire, to participate in development and
testing of system products and features.
	5.) Accessible Feature Configuration (Year Two)

Users who are persons with disabilities should have accessible applications and tools to assist them with configuring their system user
interfaces to best advantage. 

Quite often the user is left trying to configure thier own system, because
technical support staff does not have sufficient knowledge about the
available configuration options. However, most of the information these
users need can be documented and exposed in a systematic manner.

Scripted wizards and best practices documentation need to be developed to facilitate the end user by providing easy to use tools and clear,
non-technical documentation for creating appropriate configurations on individual workstations. In addition, users whose needs may vary from day to day
should have the ability to easily select an alternative configuration, as their needs change during system use.

6.)Magnification (Year Two)

Service API support for magnification should make it possible to provide
sophisticated magnification of one or more portions of the video display
screen for users who require, a larger or different font, and alternate
foreground or background color.

In addition, magnification of icons and text should be able to achieve a
wide range of magnification ratios. Many users with visual disabilities
need 3X, 4x, etc. magnification, while other users can benefit from ratios
as small as 1.2% magnification.

Currently it is not possible to achieve required magnification functionality on X platforms without requiring high-end video hardware with multiple
frame buffering. This should not be a requirement. Also, the user should be able to maintain magnification while applications are writing to the screen.

Historically the networked nature of the X technology has not made it
possible (nor desirable) for AT to replace device drivers or write directly
to video hardware. Creating this standard will require significant cooperation with
X, GNOME, and KDE developers.

There are currently projects under development, among some vendors, that
can provide reference implementations.

	7.)	Text To Speech (Year Two)


Interfaces based on synthesized text to speech (TTS) technology have proven a successful and powerful accomodation for users with various disabilities,
including persons who are blind or who have learning disabilities. A standard mechanism supporting numerous voices in numumerous languages, yet
providing a single, consistant interface to applications is prefered.

We propose to adopt or develop a standard API for TTS services capable of supporting numerous languages and including the abilityt to smoothly and
quickly switch among different languages and/or voices. This project will adopt or develop standardized mark up for spoken dialog, and provide an API
for TTS services, such as JSAPI.

People with disabilities benefit by a larger availibility of languages choices, many that may not be supported by assistive technologies today.
Providing a robust, reliable TTS interface supporting multiple voices will make it possible to facilitate the vast populations around the globe who
otherwise, might not soon participate in a tecnology based economy.

	8.)	Alternative Interface Access Protocol (Year Three)

The Alternative Interface Access Protocol (AIAP) is being developed by a technical committee of the InterNational Committee for Information Technology
Standards(see www.v2access.org). The "AIAP-URC is a standard interconnection protocol that allows users to control a mass-market device/service
(target). The URC may be a dedicated device or a feature running on a computer, a cell phone, an Assistive Technology, or other device. The key to this
approach is that the target projects a presentation-independent version of its user interface (UI) which is rendered as a concrete user interface by the
URC. The concrete UI may be visual, speech-based, braille-based, or in some other form. If desired, the manufacturer may also provide customized
concrete UIs to optimize aesthetics and usability for certain classes of users or devices. The structure of a V2 user interface definition is intended
to facilitate the use of intelligent software agents to control services and devices in the future."

A particular benefit of this technology is the XML standard whereby two devices can negotiate, in a transport independent manner, the interface that is
appropriate to a particular user. This standard will be particularly important for use in public access systems to provide user appropriate interfaces
rather than only a single user interface as is the case today. It will also be useful for providing a defined mechanism whereby a user's PDA (or similar
device) can serve as an alternate interface to a public access system and to the full range of consumer devices such as thermostats, kitchen appliances,
laundry facilities, and home security and entertainment systems..

Without this (or a similar) universal remote console (URC)technology public access and consumer technologies are likely to become even less accessible
to an ever wider range of users than they are today. Users with disabilities are often unable to use public kiosks such as ATMs, airline boarding pass
systems, etc., because they cannot use the default user interfaces provided by such systems. The INCITS V2 specs are designed to provide these
interfaces directly or to negotiate, over a secure wireless transport-independent channel with the user's personal device to provide service.

The V2Committee expects to have a candidate 1.0 specification available for ANSI certification early in 2004. We propose to adopt relevant portions of
their specifications.

	9.) Guidelines for System Administrators (Year Three)

System Administrators who are themselves persons with disabilities should be able to continue in their profession as new system administration tools are
developed. In addition, all System Administrators and technical support staff should have accessible applications and tools to assist users, to define
user interface and alternate configurations appropriate to the user's needs (including any assistive technology that the user may rely on).

Quite often the user is left trying to configure thier own system, because
the technical support staff does not have sufficient knowledge about the
available configuration options. However, most of the information these
users need can be documented and exposed in a systematic manner. Many of the tools, and much of the documentation that technical support staff would
find helpful would be the same (or similar) to that developed for users themselves (see "Accessible Feature Configuration").

Scripted wizards and best practices documentation needs to be developed to
facilitate assistance to  end users by technical support staff who may not be familiar with accessibility solutions.

10.)	Installation (Year Three)

It should be possible for persons with disabilities to install and configure a full system or individual application packages. The same considerations
that make the operational user interface accessible can be applied to the installation process.

We will develop the best practices guidance and scriptlets to support accessible installation.

11.)	Braille (Year Three)

	12.)	Structured Navigation (Year Five)

It should be possible for users to navigate the user desktop, applications, and individual documents in a straight-forward and consistant manner,
especially where a hierarchical organization is available. This project will develop an API to expose structures to user agents.

Persons who have various learning disabilities will particularly benefit from this API because developers will be able to create taylored, even
individualized interfaces that present information, available applications, documents, and media presentations that can be started, stopped, and used in
a consistant manner appropriate to the individual user.

13.)	Voice I/O (Year Five)

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina at afb.net		Phone: (202) 408-8175




More information about the Accessibility mailing list