[Accessibility] Accessibility WG Teleconference Agenda

Bill Haneman 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 :-)

thanks!

- Bill
-------------- 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, 
    very-low-vision, or
    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
    APIs.

    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 
think:


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)



More information about the Accessibility mailing list