[Accessibility] NSF Draft: Section 2
Janina Sajka
janina at rednote.net
Tue Apr 6 19:26:50 PDT 2004
And, my apologies for this formatting as well. An improved version will follow in the morning.
* __ 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