[Accessibility] NSF Draft: For Today's Call

Janina Sajka janina at rednote.net
Wed Apr 28 10:46:33 PDT 2004

* __    Summary of one page or less indicating the objectives of the project;
The Free Standards Group (FSG), Accessibility Workgroup, wishes to convene a face-to-face meeting in early 2005. At this meeting, invited experts will have in-depth face-to-face discussions to further ongoing standardization efforts in support of comprehensive access to information and accessible user interfaces for persons with disabilities. OurOur focus is on computing platforms that adopt free and  open standards, such as Linux, BSD, AIX, MacOSX, and Solaris. We request funding in  the amount of $35,000. from the National Science Foundation (NSF) in  support of this meeting.

A face-to-face conference is needed for our continued work, and is the most appropriate mechanism to:

*   Finalize proposals for industry wide accessibility standards where FSG  work has already begun;"

*   Develop a Road Map for additional open source technologies and standards to support comprehensive accessibility on open platforms;

*   Reach broad stakeholder consensus on a common layer of accessibility support that can be deployed and maintained on multiple platforms and can serve as the basis for future collaborative research to provide multiple, cost effective, interoperable, heterogenous and accessible products.

Achieving standards to support comprehensive accessibility in the free and open source environment will require participation among developer communities, marketers of free and open source technologies, and user communities. The very diverse and unstructured nature of these groups has tended to prevent adequate contact and communication among them so that excellent accessibility for some users exists in certain contexts, while other contexts remain unaddressed and inaccessible. The objectives of our international conference, therefore, are:

*   achieve consensus on those standards which can be adopted to support accessibility in the near term;

*   Agree on engineering work which must yet be performed in order to support all persons with disabilities;

* Identify areas where further targeted research is required before  engineering solutions can be put forward;

*   Enhance and extend existing relationships, and establish additional structured mechanisms to accomplish these objectives.

We plan to invite between 20 and 30 individuals from industry, developer communities, research and educational institutions, and persons with disabilities. We need to ensure broad participation across all sectors of these groups worldwide, and we need, particularly, to engage participants who would otherwise not become involved in this process.

* __    Statement of the need for such a gathering and a list of topics;
The diverse nature of the technology that constitutes today's open platform also makes 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. Yet, the open platform is an important environment for individual and institutional users alike, and especially for the research community. Without consensus among stakeholders, and without standards and binary interface components:
*    Users with various disabilities can not effectively use these systems--or major portions of these 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.

Outcomes and Benefits

The beneficiaries of the accessibility standardization activity which will be accelerated by the meeting we are proposing are numerous, cutting across all sectors engaged with either providing or using technology and include:

Persons with disabilities worldwide. They are the reason for the research and engineering work we will organize and the FSG standards which will result from it.

*	Researchers who are themselves persons with disabilities will be empowered to focus on research questions rather than on making their computing environment accessible to them.
Researchers who must now constantly address the basics of accessibility support rather than creative and innovative approaches to more complex questions will be relieved from the need to "reinvent the wheel" in order to support accessibility;

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

*	Assistive technology developers will find it easier to create more useful technologies than those available today.

*    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 others;

It is also important to note that these benefits will be available world-wide in developing and developed nations alike because neither cost nor access to the technology itself will ever 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. 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 professional careers and personal lives.

Clearly, these goals cannot be achieved in a single meeting. Our work will not be finished when we conference adjourns. However, without a face to face meeting, accessibility work on open platforms will remain a scattered enterprise without a cohesive vision that can be broadly adopted. Only a dedicated face to face event bringing together an appropriate range of knowledgable stakeholders can reach the needed consensus on standards and and identify remaining issues. We need to forge the broad consensus only a dedicated conference can achieve in order to accelarate accessibility support toward a comprehensive solution.


There has not yet been a conference devoted to the subject of defining comprehensive accessibility support on open platforms. There have been related sessions at other conferences. Several hour-long and day-long sessions addressing this and related topics have been held at conferences which tend to draw professionals working on computer and information systems accessibility such as the annual Technology and Persons with Disabilities Conference in Los Angeles (CSUN). A Linux Accessibility conference accompanied CSUN in 2002 and 2003 (see http://ocularis.sourceforge.net/).

Sun Microsystems has sponsored daylong sessions on aspects of their work, and that of others in the GNOME community, at recent CSUN conferences, at the Closing the Gap Conference, and the ATIA Conference. Sun has also presented on this topic at several European conferences of GNOME and KDE developers, most notably the annual Guadec conference (http://www.guadec.org).

Accessibility has also been discussed at recent KDE developer meetings and work on supporting accessibility in QT 4 is progressing. QT 4 will be released later in 2004, and may be previewed at the KDE Developer Conference in Germany this coming August (see http://accessibility.kde.org and http://events.kde.org/info/conference2004/overview_program.php).

The Accessibility Workgroup of the FSG has been meeting weekly since February 2003 by teleconference. Several members of this Workgroup also met in an extended working session during CSUN 2003.

The complex nature of the issues to be understood, the need for a comprehensive consensus plan to address accessibility on Linux, BSD, Solaris, Aix (and other platforms implementing free and open source technologies) however, requires a meeting apart from other issues where knowledgable stakeholders can  agree on what can be standardized today and on what work yet needs to be done.

Conference Planning and Organization

* __    Information on the location and probable date(s) of the meeting and the method of announcement or invitation; 

The Archimedes Project at the University of Hawaii, Honolulu, has extended an invitation for us to hold our meeting at the University.

It is our strong desire to schedule this conference expiditiously. We now contemplate holding the conference during the week of January 19, 2005 in Honolulu, HI, at the University of Hawaii.

Participation in this conference will be by invitation. We will invite technically conversant participation from industry, research institutions, consumer organizations, and professional associations in an effort to bring sufficient representation to achieve a consensus that can both meet the need and be implemented within shipping products. We will also invite interested individuals to request an invitation by announcing this conference on targeted email lists and at our web site, http://www.a11y.org.

Chair and Organizing Committee

The conference will be chaired by Ms. Janina Sajka, Director, Technology Research & Development, American Foundation for the Blind (AFB). Ms. Sajka also chairs the Accessibility Workgroup in the Free Standards Group. Breakout sessions will be conducted by the team lead for each project area. We will hold plenary sessions as well as break-out sessions for teams focussing on particular areas.

Additional FSG members organizing this conference include:

Dr. Greg Vanderheiden, Director
Trace Center
University of Wisconsin
{yet to be invited to this role}

Al Gilman IEEE
Dr. William La Plant (U.S. Census (retired))
{yet to be invited to this role}
{yet to be invited to this role}
Bill Haneman -- bill.haneman at sun.com billh at gnome.org
GNOME Accessibility project and SUN Microsystems Corporation
 -- bill.haneman at sun.com billh at gnome.org

Dr. T.V. Raman -- ramantv at earthlink.net
Sharon Snider -- snidersd at us.ibm.com
Randall Horwitz -- rhorwitz at us.ibm.com
Allen Wilson wilsona at us.ibm.com
IBM Corporation
{Raman yet to be invited to this role}
Jonathan Blandford Hat
Red Hat Inc.
jrb at redhat.com
{yet to be invited to this role}
John Goldthwaite --
Senior Research Scientist
Center for Assistive Technology & Environmental Access
Georgia Institute of Technology
john.goldthwaite at arch.gatech.edu

Mario Lang
maintainer of brltty & Debian accessibility
mlang at debian.org
{yet to be invited to this role}
Gunnar Schmidt --
KDE Accessibility Project
gunnar at schmi-dt.de

Kirk Reiser --
The Computer Braille Facility
University of Western Ontario
kirk at braille.uwo.ca

Matthew Wilcox, Hewlett-Packard Corporation
willy at fc.hp.com

Dr. Neil G. Scott
Director, Archimedes Hawaii Project
University of Hawaii
ngscott at hawaii.edu

Recruiting Participants

We will rely foremost on the extensive contacts of our Organizing Committee to identify, and personally invite, an appropriate representatives of stakeholder communities. These invitations will be based on the Committee's analysis of what stakholder interests exists, and what expertise we need from stakeholder representatives. Clearly, the primost stakeholder interest is that of various communities of persons with disabilities, and the Committee's widely recognized expertise will be tapped to invite the best and brightest representatives from these communities. Conference participation will be by invitation only, and all participants will be asked to make a statement regarding their interest and regarding how they believe they can contribute.

We will also prepare a web page at the Accessibility Workgroup's web site regarding this conference, inviting anyone to submit who would like to be invited to submit the same statement to the Committee for its consideration. We will further announce this conference on various targeted email lists.

Conference Agenda

Since the purpose of our conference is the development of an engineering agenda that can result in standards to support accessibility, our organization will be fairly simple. We will develop a specific agenda of issues and questions to be addressed in advance of the conference. The agenda will be published at the Accessibility Workgroup's web site at http://www.a11y.org.

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 is nevertheless necessary to obtain stakeholder consensus for AT-SPI to be adopted  industry-wide as a standard. 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 for applications  that may not have focus but have been set to monitor and report on conditions.

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. Both of these behaviors must be available to the end user.

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 and helps drive the cost of assistive technology down.

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 from public access terminals 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 educational 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