[Accessibility] AT-SPI pre-meeting information
bill.haneman at sun.com
Tue Apr 15 10:52:54 PDT 2003
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
1) It is based on queryable interfaces and objects;
2) It provides highly structured hierarchical data about
applications and interfaces, with semantic content and
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
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
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:
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:
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.
More information about the Accessibility