[Accessibility] FSG102 Part One Draft (Resend)

Janina Sajka janina at rednote.net
Tue Jul 1 11:43:50 PDT 2003

My apologies if you've already received this. I have not seen it in my
inbox so I'm resending it.

				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
-------------- next part --------------

Draft 2002-1.2.2

The formation of a new Free Standards Group Workgroup involves the
following steps (prior to and including the final proposal to the Free
Standards Group Board of Directors).

To avoid confusion and help quantify the process, the Free Standards
Group requests several documents at different points throughout the
process, which are numbered for easy reference. In addition, all
checkpoint documents should be attached to the final proposal.
Maintaining written records of these checkpoints also helps interested
parties stay focused and informed.

Unless written permission by the Executive Director or Board of
Directors, proposal organizers may not claim to represent the Free
Standards Group, but may disclose their intention to seek Workgroup
status under the Free Standards Group.


(FSG102-1) is an initial declaration of the problem and an abstract of
the proposed solution. This document should be revised throughout the
formation of the Workgroup to reflect any changes and will act as the
basic justification of further work. It should include the following:

 a. A general description of the current problem, from as many
    perspectives (user, developer, etc.) as a standard might help.

Without appropriate technological accomodations, persons with
disabilities are excluded from participating in the benefits that
technology provides. Yet technology has proven capable of delivering
unparalleled benefit to disabled users--benefits for which these
individuals usually have no other good alternatives. Whereas a device
may give voice to the words of someone who cannot speak, technology can
also prevent that individual's participation if no alternative to speech
recognition based interfacing is provided. Whereas technology can
provide the means for individuals who have not the use of their arms and
hands to write and correspond, it can also prevent them from doing so if
no alternative to using a mouse is supported. Whereas technology can
enable those who have not the use of their eyes to read online text, it
can prevent or severly encumber their ability to do so by supporting
only iconic and mouse driven user interfaces. In the vast majority of
circumstances the appropriate accomodations are known and quantifiable.
It is our proposal to codify this knowledge into binary componants that
will provide the required services in a standard manner for
implementation across any and all platforms that implement free and open

As things stand on free and open source platforms today, many (if not
most) applications are inaccessible to users who are blind, have severly
impaired vision, or live with conditions that prevent them from using
their arms and hands as most persons do. Only a very few, rudimentary
assistive technologies exist for the GUI desktop environment.
Application developers, who cannot be expected to have expertise
concerning supporting users with disabilities, have no means of meeting
application accessibility
    because there is no standard toolkit for meeting these requirements.
Assistive technology developers, who are expected to have expertise in
meeting these user requirements, have no standard API level support
suitable for obtaining the information assistive technologies require
concerning running applications. The heterogeneous nature of toolkits,
componant inter process communication models, libraries, and
applications makes the development of robust and effective assistive
technologies difficult, at best, without such standards and binary
interface componants.

    platform built-in features not available/accessible.  Multi-modal
is the direction of the future, which could be used to extend/broaden
    access but if not properly managed could pose limitations.

In addition new legal requirements emerging around the globe (such as
the Sec. 508 law in the U.S.) will require technology to support
effective usability for persons with disabilities. Marketers and
developers of free standards based technologies will need robust and
readily implementable solutions to be competitive under these
strictures. The trend toward multi-modal interfaces will help--but only
if we manage them properly. Making content creation, manipulation, and
consumption accessible will require certain visible user features as
well as API and ABI level support for developers.

 b. A very brief abstract of the proposed solution, in the form of a
    standard. The abstract should be sufficiently complete to fully
    describe the benefits of such a standard. Initially, industry or
    technical hurdles should be largely ignored. Later revisions may
    take into account more variables.

Though they may also rely on technology to assist their interface to
others and to their environment, persons with disabilities will
generally seek to perform the same tasks as all other users of
technology, it seems to us most prudent, expedient and economical to
support the accomodations they require through standards that technology
developers can adopt and implement across their product portfolios. In
proposing an Accessibility Working Group to the Free Standards Group, we
are, therefore, proposing to develop and codify such standards to the
extent that they are identifiable and implementable through Application
Binary Interfaces (and as a set of best practices) through a consensus
process among all stakeholders. In particular, we will provide:

*	A well defined standard for user features that support a
consistant experience across applications. Assistive technologies will
be required to support these features and applications must not defeat
their functionality. For instance, if we say that "Sticky Keys" is a
standard desktop feature, onscreen keyboards can rely on its presence
and be designed accordingly to take advantage of it, and can avoid
conflicting with it.  Likewise applications will then know explicitly
that they must not conflict with or defeat Sticky Keys (or any other
standard accessibility feature). Similarly, if our standards omit
certain features (for instance
if we remain silent regarding self-voicing
applications) then assistive technologies can infer
that the task of formatting an appropriate speech presentation for
applications is their responsibility.

*	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.
 c. Existing software, partial solutions, etc.  Implementations of the
    proposed standard should already exist (usually produces a less
    buggy standard), or should exist in approximate form (for example,
    no Unix complied with the first POSIX standard at the time it was
    being written, but many were close), or there should be an
    indication of what new implementation work will be needed.

We benefit from the fact that the greater majority of the requirements
have been previously 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:
                  Gnome's Keyboard Accessibility Preferences Dialog
                  XKB Specification, X.org

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

                        Java Accessibility API
                        UNO Accessibility API

         assistive-tech client-side:
                        Java Accessibility API
                        Mac Accessibility API
                        GNOME's Assistive Technology Service Provider
                        Microsoft Active Accessibility (MSAA)

Accessibility-related utilities:

          gnome-speech text-to-speech APIs
          gnome-mag magnification APIs

 d. Existing free software projects related to the proposed standard.

      X11R6/XFree86 (includes XKB)
      AT-SPI (GNOME) including libspi, libcspi, and AT-SPI's CORBA IDL.
      Java Access Bridge for Gnome (LGPL license, but requires Java 1.4)
      gnopernicus screenreader, Gnome Onscreen Keyboard
       (examples of ATs written to standard APIs)


 e. Companies and organizations in the field that would benefit from
    the standard. This should include general industry descriptions,
    as well as major potential participants.

These standards will be applicable across the entire industry.
Disability can happen to anyone, at any age. A well integrated set of
solutions will help ameliorate individuals' ability to communicate, and
to conduct professional and personal activites.

 f. Other parties that would benefit from the standard, including free
    software projects or classes of end users.

Developers of assistive technologies will be empowered to focus their
energies on the creation of innovative solutions to the particular needs
of the disabled population they serve. This, in turn, will benefit end
users in the form of more useful technology. And, because these will be
free and open standards, the benefits will be available world-wide in
developing and developed nations.

More information about the Accessibility mailing list