[Accessibility] AT-SPI pre-meeting information

[Bill Haneman]

Hello All: 

Doug has asked me about something which was on my TODO list since the
last meeting (which I missed), namely to give an overview and
introduction to AT-SPI and its context, since our proposal for AT
support ABIs would be based on AT-SPI. 

Firstly from a high-level view, AT-SPI is a 'service' API with the
following characteristics: 

1) It is based on queryable interfaces and objects; 
2) It provides highly structured hierarchical data about 
   applications and interfaces, with semantic content and 
   contextual information. 
3) It provides to generalization of user interface  
           characteristics, which means that it can be implemented by 
           toolkits 'unknown' to the API; 
    4) It is extensible; 
5) It is language-independent, i.e. bindings for many languages 
   are available, and it works in interpreted environments and   
virtual-machine environments as well as native environments; 
6) It uses an open-standards-based protocol and definition    language; 
7) It is intended as a comprehensive service API for 
           assistive technologies, i.e. ATs should not require  
           additional system APIs in order to track the state of 
           running applications and to interact with them. 
8) It uses network-transparent IPC and thus allows 
   assisitive technologies to run as independent processes 
   in a manner non-invasive to the applications' process space. 
9) It presents a homogeneous view of heterogeneous applications, 
   user interface components, and services to assistive 
           technologies. 
Because of #5 and #6, even ABI compatibility can be met without
compile-or-runtime dependencies on specific implementation libraries. 
However LGPL implementation libraries are available for reuse and 
will be bundled with most upcoming Linux distributions (and some 
proprietary Unices as well). 

The 'object' which AT-SPI exposes are the elements of the user's
computing interface.  For instance 'workspaces', 'applications',
'top-level windows', and 'user interface components' are all
"Accessibility_Object" instances and can be accessed via homogeneous
APIs.  The examples given above happen to have a hierarchical
relationship to one another which is exposed in the API via
"child-parent" relationships, which are a type of conceptual
containership.  These individual objects may be queried via the
"Accessibility_Object" interface for certain characteristics common to
all desktop elements, and may be queried as to whether various other
functionally-derived interfaces are available.  For instance an
Accessibility_Object should implement and expose the Accessibility_Text
interface if that object presents textual information onscreen in the
form of glyphs.  Querying an object for an interface thus gives
information about the functional capabilities of the object; an
Application object does not, for instance, implement Accessibility_Text,
but it does implement the core Accessibility_Object interface.  To take
another example, the Accessibility_Component interface is implemented by
all objects which occupy on-screen "real estate".  This points out the
fact that the AT_SPI interfaces can be applied not only to graphical
user interfaces but to other types of interface as well. 

Before we go further into the AT-SPI interfaces I would like to provide
some context in terms of the whole accessibility stack.  Since AT-SPI's
implementation is a full-featured IPC service, writing AT-SPI code on
the server side can be nontrivial.  In practice it is usually preferable
for specific UI toolkits (such as the Mozilla XUL toolkit, GTK+,
Java-Swing, and OpenOffice's VCL-based widget set) to provide their own
"in-process" internal accessibility APIs.  The primary requirement is
that these internal APIs map onto the AT-SPI feature-for-feature.  In
this way, the individual UI components (i.e. widgets) can implement
accessibility via toolkit-appropriate APIs and techniques without
incurring dependencies on specific IPC implementation code.  A thin
"bridging layer" is then provided which translates each of the internal
interfaces into the common AT-SPI ABI.  A one-to-one feature mapping
makes for the lightest and most efficient bridges.  Note that individual
implementations of the interfaces do _not_ need to be bridged; bridging
code need to be written only "per interface" and not "per widget". 

In the existing "GNOME" implementation (this term is somewhat
inaccurately applied to GTK+, GNOME, OpenOffice, and Java), the
respective accessibility APIs are as follows: 

* GTK+ : ATK 
* GNOME : ATK 
* Mozilla : ATK (note that the Mozilla team chose to reuse the  
                         ATK bridging layer) 
* Java/Swing : the "Java Accessibility API" 
* OpenOffice : UNO Accessibility API ("XAccessible") 

Furthermore, the OpenOffice code currently bridges internally to the
Java Accessibility API from the UNO internal accessibility API. 
Therefore there are only two currently-existing "bridges", the "Java
Accessibility Bridge for AT-SPI" and the "ATK Bridge", and these two
bridges are reused by all the existing toolkits. 

If we consider as an example how one would provide binary-compatible
AT-SPI services for KDE/Qt, two immediate candidates emerge:

	1) Qt and KDE could implement its own in-process accessibility
	API which mirrored the AT-SPI interfaces, and bridging code
	(which would be dynamically loaded at runtime) would be written
	to export the appropriate ABI, OR;

	2) KDE could reuse the ATK interface definitions as the 	 	  
in-process API/ABI, and thus reuse the existing "ATK-bridge".
	  
Option #2 is the more expedient of the two, and is the plan of record
for the "kde accessibility project", though resourcing to do the work
hasn't been identified yet.  This was also the approach taken by Mozilla
and is similar to the way the StarOffice/OpenOffice accessibility code
works, i.e. by reusing an existing bridge.  Option #1 would not involve
any direct dependencies on glib, but writing the bridging code would be
a much larger undertaking than reusing the existing bridge.

There is a third option, bridging directly to AT-SPI from KDE/Qt, but I
think that it's unlikely to be attractive because of the level of effort
involved.

Thus the AT-SPI/ATK (aka "GNOME") Accessibility architecture is a
layered architecture and components, toolkits, and applications can plug
into it at various levels depending on their needs and requirements.

We have not yet discussed the issue of application certification or ABI
standards at the application level.  Personally I think that in order to
remain as toolkit-neutral as possible we may avoid any ABI specification
at the application level and restrict our conformance criteria to
functional ones, or test conformance at the AT-SPI platform layer only.

For more information about these APIs, the IDL for AT-SPI (which defines
a normative ABI in conjunction with the public CORBA-2.2 standard) is
available for perusal from:

http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=at-spi/idl

HTML documentation for ATK, which is easier to read and has a one-to-one
correspondance with the AT-SPI APIs, is available at this URI:

http://developer.gnome.org/doc/API/2.0/atk/book1.html

I suggest that reading the ATK documentation may be a better
introduction, and one would just keep in mind that the actual ABI would
be more-or-less the same with respect to features but would not use the
same binary structures and ABI as ATK.  (Note that the ATK docs are not
very friendly to Lynx users but they should work with other
browser/screenreader combinations; we are working to remedy that).

I hope that this document serves as a basis for discussion tomorrow and
I will be happy to answer any questions during the concall.

regards,

Bill