• 1 Open Accessibility Workgroup Charter
  • 1.1 1. Identify Problem and Proposed Solution Abstract
    • 1.1.1 1A) A general description of the current problem.
    • 1.1.2 1B) A brief abstract of the workgroup's proposed solution, in the form of a standard.
    • 1.1.3 1C) Existing Software & Partial Solutions.
    • 1.1.4 1D) Existing free software projects related to the proposed standard.
    • 1.1.5 1E) Companies and organizations in the field that would benefit from the standard.
    • 1.1.6 1f) Other parties that would benefit from the standard, including free software projects or classes of end users.
  • 1.2 2. Initial Party Involvement
    • 1.2.1 2A) Policy Agreement
    • 1.2.2 2B) Technical Agreement
      • 1.2.2.1 2B.1) AT-SPI (Year One)
      • 1.2.2.2 2B.2) AT Device Shared I/O (Year One)
      • 1.2.2.3 2B.3) Keyboard Accessibility (Year One)
      • 1.2.2.4 2B.4) Text-only accessible booting (Year Two)
      • 1.2.2.5 2B.5) Accessible Feature Configuration (Year Two)
      • 1.2.2.6 2B.6) Magnification (Year Two)
      • 1.2.2.7 2B.7) Text To Speech (Year Two)
      • 1.2.2.8 2B.8) Alternative Interface Access Protocol (Year Three)
      • 1.2.2.9 2B.9) Guidelines for System Administration (Year Three)
      • 1.2.2.10 2B.10) Installation (Year Three)
  • 1.3 3) Core Participants List
    • 1.3.1 3A) Task Outline

Version 1.0 – 16 Sept 2003

Far too often people with disabilities are excluded from participation in the benefits that technology provides in society today. Though it may be unintentional, this exclusion remains far too common because the needs of users with disabilities are rarely considered appropriately (if at all) in the design process. Consequently, many of today's technology products and services remain inaccessible to, or only marginally usable by persons with disabilities. However, it has also been widely demonstrated that technology can profoundly enhance the lives of persons with disabilities. A properly designed technology tool is often a disabled person's best choice for active participation in society–whether at home, at work or at play.

Adherence to some simple criteria in software design, such as provision of keyboard navigation and adherence to user-specified system appearance settings can reduce or eliminate these barriers for many users, including users who may not identify themselves as 'disabled'. It is furthermore well known that properly designed assistive technologies (AT) are capable of delivering unparalleled benefits to users with more severe disabilities who usually have no other viable alternative for performing many common tasks.

Assistive technologies can:

• provide the means for individuals, who do not have the use of their arms and hands, to write and correspond. Often user interfaces programmatically prevent these users from performing important tasks simply by not providing mouse and keyboard alternatives.
• enable individuals who are blind or visually impaired to read online text. Often user interfaces programmatically prevent or severely encumber the users ability to read and traverse the screen by only supporting graphical, mouse driven user interfaces.
• support participation by individuals who can't speak or hear on today's telephony interfaces and tomorrow's multimodal computer interfaces.

There are many needless barriers that could be readily removed by systematically providing appropriate contextual information to both applications and system services through well-defined standards of practice (and adherence to those standards).

In addition, standards facilitate the creation and distribution of assistive/adaptive technologies and user agents appropriate to a range of end-user abilities and ensure that applications and operating system services operate in cooperation, rather than in conflict, with such technologies.

The accessibility workgroup proposes to provide the standards and the best practices guidance for the implementation of consistent and robust user support for individuals with disabilities across any and all platforms that implement free and open standards.

Currently, free and open source platforms have many graphical user interface (GUI) applications that are inaccessible to users who are blind, have severely impaired vision, or live with mobility impairments that prevent them from using their arms and hands. Only a very few, rudimentary assistive technologies exist for the GUI desktop environment. Application developers may not have the expertise needed to write accessible applications that meet the requirements of users with disabilities. At present there is not a standard toolkit for meeting these requirements.

Assistive technology developers are expected to have the expertise needed to meet these user requirements. However, the developers must have standard API level support that provides the information required for assistive technologies to run properly on all applications.

The heterogeneous nature of toolkits, component inter process communication models, libraries, and applications can make the development of robust and effective assistive technologies difficult, at best. Without standards and binary interface components:

• Users with various disabilities can not effectively use the system.
• systems do not meet legal requirements (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 the existing work, sharing of expertise, and reduces the value of individual contributions.

People with disabilities generally seek to perform the same tasks as any other technology users. In addition, many disabled users rely on assistive technologies to provide access to the GUI desktop environment. We believe it is prudent, expedient, and economical to support the accommodations that users with disabilities require through standards that developers can adopt and implement across their product portfolios.

In proposing an Accessibility workgroup to the Linux Foundation, we are, therefore, proposing to develop and codify such standards to the extent that they are identifiable and can be implemented through Application Binary Interfaces (and as a set of best practices), and through a consensus process among all stakeholders. In particular, the workgroup will provide:

• A well defined standard for user features that support a consistent experience across applications. Technologies that are required to support these features and applications must not defeat the intended functionality. For example, if the standard states that “Sticky Keys” is a standard desktop feature, onscreen keyboard application developers can rely on the presence of “Sticky Keys” and design applications that take advantage of this function, while avoiding keyboard conflicts.
• A comprehensive standard for application program interfaces to support the development of robust assistive technologies across the heterogeneous free standards environment. It is imperative to provide for a dynamic nexus between applications and assistive technologies so that characteristics such as time-out or keystroke event injection can be adjusted appropriately.

We benefit from the fact that the greater majority of requirements to support users with disabilities are well understood. Several generations of technologies for supporting users with disabilities have previously been implemented, sometimes on several platforms, though usually on proprietary ones. The value and viability of such standards is, therefore, well established. The most comprehensive solutions available today were created for Microsoft Windows computers. An incomplete solution has long been available on Macintosh computers. Elements exist for free and open platform desktops, and significant robust solutions for certain user communities are well established on the console side of free and open platforms. Examples include:

keyboard accessibility:

• end-user features:
  • AccessX
  • Gnome's Keyboard Accessibility Preferences Dialog

• APIs/ABIs:
  • XKB Specification, X.org
  • word completion APIs
  • brltty (Braille display access APIs)

Accessibility APIs/ABIs (i.e. existing open solutions and also prior art in the proprietary domain):

• applications-side:
  • ATK
  • Java Accessibility API
  • UNO Accessibility API (StarOffice/OpenOffice.org)

• assistive-tech client-side:
  • GNOME's Assistive Technology Service Provider Interface (AT-SPI)
  • Java Accessibility API
  • kttsd APIs
  • Mac Accessibility API
  • gnome-mag magnification API
  • gnome-speech text-to-speech AP

• ATK
  • AT-SPI (GNOME) including libspi, libcspi, and AT-SPI's CORBA IDL.
  • brltty (libbrlapi)
  • Console508
  • Emacspeak
  • Festival
  • GNOME
  • gnome-mag
  • Gnome Onscreen Keyboard (GOK)
  • gnome-speech
  • gnopernicus screenreader (examples of an AT written to standard APIs)
  • Java Access Bridge for Gnome (LGPL license, but requires Java 1.4)
  • KMagnifier
  • KMouseTools
  • KMouth
  • kttsd (KDE TTS Daemon)
  • Speakup
  • X11R6/XFree86 (includes XKB)

These standards will be applicable across the entire industry. We will, therefore, look for representative participation throughout the industry.

Application developers will be empowered to support users with disabilities in a straight forward manner.

Marketers of distributions based on free standards will be able to include accessibility support in their distributions which, in turn, will enable them to meet legal requirements in various markets worldwide (such as in sales to U.S. Government entities).

Developers of assistive technologies will be empowered to focus their energies on the creation of innovative solutions to the particular needs of the specific disabled population they serve.

The beneficiaries of these standards are similarly numerous, cutting across all sectors engaged with either providing or using technology.

Implementations of free standards such as GNOME, KDE, and GNU software

• Vendors of Unix and Linux such as Red Hat Inc., Sun Micro Systems, 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, IBM Corporation, and Motorola Corporation, among others.

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 LF Accessibility Standards will, of course, be persons with disabilities worldwide. They are the reason for these standards. However, the wider world of developers and marketers of technologies based on free standards will also benefit.

Users with disabilities will:

• Find compatible free as well as commercial software more useful and usable.
• Enjoy consistent, integrated accessibility from boot-up to shutdown in both console and desktop environments–wherever they might need it.
• Find personal and public devices and systems, such as telephones, personal data assistants (PDA), entertainment systems, public kiosks, banking and voting machines, useful and usable.

The world of free standards based technology will:

• Extend its coverage to support any and all users regardless of disability, physical, or sensory condition.
• Increase participation in future software development.
• Become yet more robust, innovative, and generally attractive to all users by integrating multiple ways by which users can access information and perform tasks.
• Meet, and even exceed, social and legal mandates requiring inclusion of persons with disabilities in electronic and information technologies.
• Expand into new market segments and provide business' the ability to compete effectively in markets where accessibility is a selection criterion.

It is 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.

The following 19 people have been involved with creating this document and putting together the formation of this proposed workgroup. Just prior to this document being presented to the Board of Directors for consideration, a vote was taken on agreement to the contents shown here. All but 3 of the participants responded, voting yes, to accepting the document as presented. (We are still waiting on responses from: Pupeno, Marco, and Jan).

1. Janina Sajka – janina@afb.net (American Foundation for the Blind)
2. Bill Haneman – bill.haneman@sun.com billh@gnome.org (GNOME Accessibility project and SUN Microsystems)
3. JP Schnapper-Casteras – jpsc@stanford.edu (University of Wisconson Trace Center)
4. Sharon Snider – snidersd@us.ibm.com (IBM Linux Accessibility - Linux Technology Services)
5. Randall (Randy) Horwitz – rhorwitz@us.ibm.com (IBM Accesssibility Center)
6. Allen Wilson wilsona@us.ibm.com (IBM Accesssibility Center)
7. Jonathan Blandford Hat – jrb@redhat.com (Red Hat Inc.)
8. Jennifer Lamb – jlamb@redhat.com (Red Hat Inc.)
9. John Goldthwaite – john.goldthwaite@arch.gatech.edu (GA Tech - Senior Research Scientist over accessibility team, Center for Assistive Technology & Environmental Access)
10. Mario Lang – mlang@debian.org (Debian representative, maintainer of brltty & Debian accessibility)
11. (Pupeno) Jose Pablo Ezequiel Fernandez – pupeno@kde.org (KDE developer)
12. Aaron J. Seigo – aseigo@kde.org (KDE developer)
13. Gunnar Schmidt – gunnar@schmi-dt.de (KDE Accessibility Project)
14. Kirk Reiser – kirk@braille.uwo.ca (The Computer Braille Facility University of Western Ontario; Author of Speakup screen reader)
15. Matthew Wilcox (Willy) – willy@fc.hp.com (HP Linux Kernel developer monitoring Accessibility issues)
16. Marco Skambraks – marco@suse.de (SuSE's representative)
17. TV Raman – tvraman@almaden.ibm.com (IBM - Author of EmacSpeak software)

Monitoring the group until an engineer is appointed is:

• Jan Aarsaether – N/A (Technical Sales Manager of Trolltech Inc.)

Acting as an advisor when requested:

• Neil Scott – N/A (Leader and Chief Engineer of the Archimedes Project at Stanford's Center for the Study of Language and Information)

Neil acts in an advisory role. He has been a member of several White House committees on access issues and is a frequent reviewer of disability-related grants for the National Science Foundation.

The participants have all agreed upon the following items as important work for this group:

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. The AT-SPI enables developers and distributions to meet the accessibility requirements of many individual and corporate customers.

AT-SPI is an existing mature API that we propose to adopt.

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 simultaneously.

In some circumstances 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 supress until a particular window or console has focus.

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 simplifies the development of accessibility related software by sharing commonly used code such as low-level driver implementations in these libraries.

Two representative candidate libraries/APIs providing this service for braille devices, libbrl and brltty, are already available on the Linux platform.

Persons unable to use a keyboard and mouse sometimes use alternative devices. However, many users can be accomodated 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 available at http://ftp.x.org/pub/R6.4/xc/doc/specs/XKB/XKBlib/allchaps.ps.

“Sticky Keys” is one 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.

We propose to identify and adopt a subset of the XKB specification in order to provide standard keyboard features and behaviors required by persons with mobility impairments.

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. We will support/coordinate the development of best practices and coordinate 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 supported.

This will particularly benefit those users with disabilities who are technology professionals and need, or desire, to participate in development and testing of system products and features.

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.

We will support/coordinate the development of scripted wizards and best practices documentation to facilitate the end user by providing easy to use tools and clear, non-technical documentation for creating appropriate configurations on individual workstations. For users whose needs may vary from day to day, we will support/coordinate the development of scripted mechanisms to allow users to select an alternative configuration easily, as their needs change during system use.

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. We will support/coordinate the development of enhanced windowing technologies capable of supporting magnification technologies more robustly and appropriately. 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.

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 mechanism supporting numerous voices in numumerous languages, yet providing a single, consistant interface to applications is preferred.

We will support/coordinate the development of a standard API for TTS services capable of supporting numerous languages and including the ability to smoothly and quickly switch among different languages and/or voices. This project will adopt or develop standardized mark up for spoken dialog, and provide an API for TTS services, such as JSAPI.

People with disabilities benefit by a larger availibility of languages choices, many that may not be supported by assistive technologies today. Providing a robust, reliable TTS interface supporting multiple voices will make it possible to facilitate the vast populations around the globe who otherwise, might not soon participate in a tecnology based economy.

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 URC may be a dedicated device or a feature running on a computer, a cell phone, an Assistive Technology, or other device. The key to this approach is that the target projects a presentation-independent version of its user interface (UI) which is rendered as a concrete user interface by the URC. The concrete UI may be visual, speech-based, braille-based, or in some other form. If desired, the manufacturer may also provide customized concrete UIs to optimize aesthetics and usability for certain classes of users or devices. The structure of a V2 user interface definition is intended to facilitate the use of intelligent software agents to control services and devices in the future.”

The objective of the AIAP standard is to allow two devices to negotiate, in a transport independent manner, the interface that is appropriate to a particular user. This standard will be especially important for use in public access systems to provide user appropriate interfaces rather than only a single user interface as is the case today. It will also be useful for providing a defined mechanism whereby a user's PDA (or similar device) can serve as an alternate interface to a public access system and to the full range of consumer devices such as thermostats, kitchen appliances, laundry facilities, and home security and entertainment systems.

Without this (or a similar) universal remote console (URC)technology public access and consumer technologies are likely to become even less accessible to an ever wider range of users than they are today. Users with disabilities are often unable to use public kiosks such as ATMs, airline boarding pass systems, etc., because they cannot use the default user interfaces provided by such systems. The INCITS V2 specs are designed to provide these interfaces directly or to negotiate, over a secure wireless transport-independent channel with the user's personal device to provide service.

The V2Committee expects to have a candidate 1.0 specification available for ANSI certification early in 2004. We propose to adopt relevant portions of their specifications.

System Administrators who have disabilities should be able to continue in their profession as new system administration tools are developed. In addition, all System Administrators and technical support staff should have accessible applications and tools to assist users, to define user interface and alternate configurations appropriate to the user's needs (including any assistive technology that the user may rely on).

Linux and Unix environments arguably have the most accessible documentation of any operating system today. The console environment is arguably the most accessible environment for many computer professionals with disabilities today. We wish to ensure that free and open operating environments remain the most accessible and inclusive platforms available even as the tools used by system administrators (and other computer professionals) become more sophisticated.

Professional system and application administrators are responsible for the installation, configuration, and management of a system's operating system, applications, and system management tools. An example is a system running the Apache HTTP server using a “Web-based Distributed Authoring and Versioning” (WebDAV) tool. Administrators use commands, tools, and documentation that are not normally useful to nonadministrative users. We will support/coordinate the use and adoption of LF accessibility standards and best practices for all applications, including operating system and application administration resources. We will support/coordinate the development of best practices and tools documentation to facilitate assistance to end users with disabilities by technical support staff who may not themselves be familiar with accessibility solutions.

It should be possible for persons with disabilities to install and configure a full system or individual application package. The same considerations that make the operational user interface accessible can be applied to the installation process.

We will support/coordinate the development of scripted wizzards and best practices documentation to support accessible installation.

Consult section 2a for a list of core participants. These individuals have been instrumental in putting together the details of this proposed workgroup and will remain as core participants.

The overall tasks for years one through three have been documented in section 2B. Other tasks being considered through year five can be found on our proposed roadmap.

The group has discussed and plans on providing written specifications, as well as references to current specifications and standards, as discussed in the other sections of this document. It will also form a subgroup whose purpose will be to develop and provide test suites to be used in a certification process. The certification process will be for validating compliance to the standards set forth by this group, and will be similar in nature to those currently being used by the LSB group. The standards and specifications provided by this proposed workgroup will be seen as an add on module to the core LSB specifications when resolutions and direction to accessibility issues are needed.