[Accessibility] Draft AT-SPI Goals Statement From Bill

Janina Sajka janina at freestandards.org
Wed Oct 25 09:31:28 PDT 2006

I'm taking the liberty to forward this to our entire FSGA. While it
seems we don't have a pre FSGA discussion with Ian arranged this week,
I'm proposing we continue last week's discussion based on your excellent draft.

Bill Haneman writes:
> Attached, my "page" in its current state.
> Bill

> GOALS for LSB/FSG standardization of AT-SPI interface for a11y
> The "Assistive Technology Service Provider Interface", or AT-SPI, defines a set of client-server interfaces by which assistive technologies can:
> (a) access information about running applications via query, 
> (b) receive notification of changes to the state of those applications and the component parts of their  	(usually graphical) interfaces, and
> (c) interact with those running applications and with the desktop I/O system on behalf of the user.
> Assistive (or Adaptive) Technologies provide supplemental or replacement interface modalities for users who cannot use the computer most effectively via the standard user interfaces (both hardware and software).
> By its nature, AT-SPI is cross-process, requiring RPC/IPC (remote procedure calls/interprocess communication).  The version of AT-SPI available at present uses CORBA as its wire protocol, and the native client and server ABIs are defined by the application of the CORBA specification to interfaces defined via AT-SPI's Interface Definition Language (IDL).  The Object Management Group (OMG's) CORBA specification defines a standard set of bindings for multiple languages such as C, C++, Java, and Python.
> However, CORBA as a technology is relatively unloved in the desktop space.  It has few supporters within the Gnome developer community, where it is widely considered deprecated; and its adoption has historically been actively opposed within the KDE community.  Another IPC technology has been developed with input from both Gnome and KDE, and is known as D-BUS.
> While D-BUS is not yet a drop-in replacement for our CORBA technology, there is motivation for migrating AT-SPI to it in the future, or for providing a D-BUS workalike which exports interfaces which are API compatible (though not ABI compatible).  
> Unlike many FSG standards, AT-SPI is of limited use without complete interoperability.  Whereas most LSB ABIs provide client applications what they need simply by being available on the platform, AT-SPI is only of value to its clients if it is implemented, as a service, by a significant proportion of the platform's other applications.  
> In face-to-face meetings of the FSG Accessibility Workgroup, and in follow-on discussions, our plan of record for allowing AT-SPI to enter an FSG standardization process has been as follows:
> 1) We wish to make the IDL-defined interfaces in AT-SPI the normative part of the interface.  These IDL files define interface names, methods, parameter types, and, where feasible, semantics.
> 2) Recognizing that interfaces can only meaningfully be standardized if they can be validated, we intend to conformance test against specific ABIs derivative of the IDL.  However, knowing that the presently existing ABI introduces dependencies which are not in the long-term interests of interoperability and cooperation, we wish to propose to explicitly plan for other, parallel, conformance tests with alternate ABIs in the future.
> Our goal is for future platforms to be able to conform to our AT-SPI spec without requiring that they be ABI-compatible with the existing implementation.  This is of course a weaker guarantee than what LSB normally gives, but realistically we anticipate that since we will want to define an acceptance process for alternate ABIs, the number of such ABIs in existance will be small, and clients will at most need to re-compile some fraction of code for compatibility.  In fact virtually all of the current clients of AT-SPI access it either via Python bindings (which can be imported at runtime from different ABIs in a client-transparent way), or via a set of C wrappers called "cspi" (which for technical reasons we do not wish to propose as our ABI); this means that in practice a client may only need to re-link or import a different symbol set in order to run in either ABI environment.


Janina Sajka				Phone: +1.202.595.7777
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org

More information about the Accessibility mailing list