[Accessibility] NSF Draft: Section 2 Need
Janina Sajka
janina at rednote.net
Wed Apr 7 08:40:59 PDT 2004
* __ Statement of the need for such a gathering and a list of topics;
As noted above, the very diverse and unstructured nature of
stakeholder constituencies which must agree to create a common
layer of accessibility support on open platforms has tended to
prevent the contact and communication needed to achieve such a
goal. There simply has not been an industry forum to support such
an effort--until now. The diverse nature of the technology that
constitutes today's open platform has also made it very difficult
to achieve a comprehensive and cohesive layer of accessibility
support. The heterogeneous nature of toolkits, component inter
process communication models, libraries, and applications on free
and open source platforms has made the development of robust and
effective assistive technologies difficult, at best. Without
consensus among stakeholders, and without standards and binary
interface components:
* Users with various disabilities can not effectively use
the systems.
* Systems do not meet legal requirements for
accessibility (which hampers marketing of free
standards based systems).
* Developers cannot consistently write accessible
applications.
* Comprehensive and consistent platform services that
support accessibility do not exist.
* Assistive technology developers cannot create assistive
technologies for free standards platforms.
* The lack of standardization prevents leveraging
existing work, sharing of expertise, and reduces the
value of individual contributions.
The beneficiaries of the accessibility standardization activity
which will be accelerated by this meeting are numerous, cutting
across all sectors engaged with either providing or using
technology and include:
* Implementations of free standards such as GNOME, KDE,
and GNU software
* Vendors of Unix and Linux such as IBM Corporation,
Novell Corporation, Red Hat Inc., Sun Micro Systems,
and United Linux, among others.
* Vendors of hand-held devices, consumer and business
products using embedded technologies, as well as those
providing large industrial systems such as
Hewlett-Packard Corporation and IBM Corporation, among
other;
* Both individual consumers and institutional ones such
as governmental agencies and educational institutions,
many of which are now legally required to support
accessibility.
The principle beneficiaries of FSG Accessibility Standards will,
of course, always be persons with disabilities worldwide. They
are the reason for the engineering work we will organize and the
FSG standards which will result from it. However, it is also
important to note that these benefits will be available
world-wide in developing and developed nations alike because cost
will never be a barrier to anyone's participation, either as an
end user or as a technical contributor. This is a fundamental
benefit of open source technology. It explains why research
institutions tend to prefer open platforms for their activities.
And, by including accessibility support through a common layer
that all platforms can adopt, persons with disabilities will be
empowered to participate at any level in technology's benefits
throughout their lives.
The conference agenda will include work on FSG's current
accessibility standardization efforts and on developing a Road
Map, with timelines and deliverables, which can point the way to
a comprehensive solution that is implementable incrementally.
Specific topics which must be addressed and will be discussed at
this conference include:
Part A: Current Tasks
1.) AT-SPI
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 the Qt toolkit (on which KDE is
based) 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.
Yet, adopting the AT-SPI as a standard that platforms and
products can certify against is a somewhat different
approach for many in the open standards community. So, while
the technology approach may be sound, it will nevertheless
be necessary to obtain stakeholder consensus. It will also
be necessary to devise and agree on certification
procedures.
2.) AT Device Shared I/O
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 which a user may
have open. Not only does the system as a whole need to
provide appropriate behavior to an application which
currently has focus, it should facilitate programmatically
determined output in an appropriate manner aswell.
Because applications which support accessibility have
historically been developed by isolated communities, they do
not necessarily operate without impinging upon one another
today. In some circumstances, for example, 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 suppress until a particular window or
console has focus.\
This activity supports a seamless user experience from
bootup, in the console and desktop environments, and through
shutdown.
We will support/coordinate the development of 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, to use those libraries independent of
the actual hardware in use. This, in turn, simplifies the
development of accessibility related software.
3.) Keyboard Accessibility
Persons unable to use a keyboard and mouse sometimes use
alternative devices. However, many users can be accommodated
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.
Yet some of these features are today in danger of being
removed from XKB because its maintainers are no longer aware
of how critical they are to certain users. We will protect
and extend these important technologies by engaging all of
the stakeholders in the creation of an internationally
acknowledged standard against which platforms and products
can certify.
"Sticky Keys" is one such keyboard accessibility feature
provided in the XKB specification. It supports users who
cannot press key combinations. For example, the user is
unable to press the Ctrl-Alt-TAB keys simultaneously, Sticky
keys allows 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.
Part B: Future Activities
The FSG Accessibility Workgroup has named several areas which it
believes require additional engineering development and
standardization. While we do not believe this list is exhaustive,
we do believe it can serve to start the all important discussions
on creating a Road Map for comprehensive accessibility on open
platforms. Thus, the Road Map produced by the conference we are
proposing may include all or some of the following activities:
1.) Magnification
One critical area requiring engineering and standardization
is support for magnification in Xwindows applications.
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.2X 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.
2.) Text To Speech
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 API supporting numerous voices in numumerous
languages, and supporting the ability to smoothly and
quickly switch among different languages, yet providing a
single, consistant interface to applications does not exist
today. Such an API is needed if conversational foreign
language education is one day to be made available. People
with disabilities will also benefit by a larger availibility
of language choices in spoken interfaces, many that may not
be supported by assistive technologies today. Providing a
robust, reliable TTS interface supporting multiple voices
will also make it possible to facilitate the vast
populations around the globe who otherwise, might not soon
participate in a tecnology based economy.
3.) Alternative Interface Access Protocol
The Alternative Interface Access Protocol (AIAP) is being
developed by a technical committee of the InterNational
Committee for Information Technology Standards (INCITS) (see
www.v2access.org). The AIAP provides for a Universal Remote
Console (URC) "that allows users to control a mass-market
device/service (target). The target projects a
presentation-independent version of its user interface (UI)
which is rendered as a concrete user interface by the URC
and may be visual, speech-based, braille-based, or in some
other form. This activity dovetails with current emphasis
within the World Wide Web Consortium (W3C) on the
development of device independent, multi-modal XML markup
technologies. Incorporating these developments into a common
accessibility support layer on open platforms can facilitate
accessibility for a host of common devices such as public
access terminals, and to the full range of consumer devices
such as thermostats, kitchen appliances, laundry facilities,
and home security and entertainment systems. Without support
for this (or a similar) universal remote console
(URC)technology in SDKs, public access and consumer
technologies are likely to become even less accessible to an
ever wider range of users than they are today. Withit, ever
more research and education opportunities can be made
accessible where they are not accessible today.
4.) Text-only accessible booting
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. This will
require coordination 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 customarily supported. This will particularly
benefit those users with disabilities who are technology
professionals or scientific researchers and need, or desire,
to participate directly in the development and testing of
products.
5.) Accessible Feature Configuration
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 their 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. In
particular, we are concerned to devise technologies which
facilitate rapid configuration and adaptation as users move
from one device to another, or as a user's needs change
during the day.
--
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