[Accessibility] Accessibility WG Teleconference Agenda
bill.haneman at sun.com
Wed Jun 25 12:11:09 PDT 2003
> c.) Document 102--the Working Group Proposal
Regarding this proposal, I attach my very rough notes interleaved with
the text of the FSG document which describes what the "102" document is
about. The FSG text is prefixed with "|".
I hope we get lots of re-wording and additional text starting from this
nucleating point :-)
-------------- next part --------------
|1. IDENTIFY PROBLEM AND PROPOSED SOLUTION ABSTRACT
|(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.
user: Unix/Linux applications are not accessible to blind,
seriously mobility impaired users since assistive techs are not available.
developer: no means of meeting application accessibility requorements
since there is no standard for OS/toolkit=level support.
AT developer: there are no existing standard APIs suitable for obtaining
accessibility information about running applications. Heterogeneous
nature of toolkits, apps, and component/IPC models on Linux/Unix make
development of assistive techs difficult or impossible without such
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 order to meet new regs such as US 508, developers need more
support at the platform level. Also in order to provide the broadest
access to content a platform must provide certain user-visible features
as well as developer APIs and ABIs.
|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.
standard for features, to assist in consistency of user experience and to
help define the "standard" features with which ATs must work and whose
operation applications should not defeat. 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 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 don't say anything about self-voicing apps) then ATs can infer
that the problem of formatting appropriate speech presentation for
applications lies with the ATs.
standard for APIs, so that portable assisitive technologies can be built,
and so that ATs can work with the heterogeneous computing environment.
(And for apps to write to, to enhance or supplement their accessibility,
i.e. LONGDESC) Also standards for APIs so that utilities and applications
which need access to relevant facilities such as timeout or configuration
values can get them (ex: key event injection).
| 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.
LOTS of fleshing out here, but the basic categories that exist, I
Gnome's Keyboard Accessibility Preferences Dialog
XKB Specification, X.org
Accessibility APIs/ABIs: (i.e. existing open solutions and also prior art
in the proprietary domain):
Java Accessibility API
UNO Accessibility API (StarOffice/OpenOffice.org)
Java Accessibility API
Mac Accessibility API
GNOME's Assistive Technology Service Provider Interface
Microsoft Active Accessibility (MSAA)
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)
More information about the Accessibility