[Accessibility] FSG102 -- Part One (Draft)

Bill Haneman bill.haneman at sun.com
Wed Jul 2 10:23:05 PDT 2003

On Tue, 2003-07-01 at 08:51, Janina Sajka wrote:
> 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.

[a few spelling errors corrected]:

Without appropriate technological accommodations, 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 on-line text, it
can prevent or severely encumber their ability to do so by supporting
only iconic and mouse driven user interfaces. In the vast majority of
circumstances the appropriate accommodations are known and quantifiable.

> It is our proposal to codify this knowledge into binary components that

[not sure 'codify this knowledge into binary components' is clear
enough, has an odd taste to it :-)]

"Provision of the appropriate contextual information and both
application and system services via well-defined standards, and
adherence to clearly defined standards of practice will remove needless
barriers to entry in several ways.  Firstly, by facilitating the
creation and distribution of assistive/adaptive technologies and user
agents appropriate to a range of end-user abilities; and secondly by
ensuring that applications and system services operate in cooperation
with, rather than in conflict with, such technologies."

> will provide the required services in a standard manner for
> implementation across any and all platforms that implement free and open
> standards.

[my revision above omits "free and open standards" which we should
weave back in somehow I think.]

[spelling corrected below]:

As things stand on free and open source platforms today, many (if not
most) applications are inaccessible to users who are blind, have severely
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 requirements 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,
component 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 components.
>     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 accommodations 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
> consistent 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, on-screen 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.

[Janina - not sure how this observation fits into FSG102.]
> *	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:
>                   AccessX,
>                   Gnome's Keyboard Accessibility Preferences Dialog
>          APIs/ABIs:
>                   XKB Specification, X.org
> 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:
>                         Java Accessibility API
>                         Mac Accessibility API
>                         GNOME's Assistive Technology Service Provider
> Interface
>   (AT-SPI)
>                         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)
>       GNOME
>       AT-SPI (GNOME) including libspi, libcspi, and AT-SPI's CORBA IDL.
>       ATK
>       gnome-mag
>       gnome-speech
>       Java Access Bridge for Gnome (LGPL license, but requires Java 1.4)
>       gnopernicus screenreader, Gnome Onscreen Keyboard
>        (examples of ATs written to standard APIs)
> Speakup
> Brltty
> Emacspeak
> Console508
>  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.

[Janina, I would explicitly mention GNOME, KDE, GNU, perhaps the 
Linux distributors, and major Unix/Linux vendors here.]

>  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.
> -- 
> 				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
> _______________________________________________
> Accessibility mailing list
> Accessibility at freestandards.org
> http://www.freestandards.org/cgi-bin/mailman/listinfo/accessibility

More information about the Accessibility mailing list