[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

     *    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

     *    Both individual consumers and institutional ones such
          as governmental agencies and educational institutions,
          many of which are now legally required to support

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

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

     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

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