[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