[Accessibility] Summary of the LSB accessibility discussion

Olaf Schmidt ojschmidt at kde.org
Wed Dec 13 10:54:38 PST 2006


This is a summary of the accessibility discussion at the LSB face-to-face 

Short summary:

Our aims were:
1. Getting acceptance from the LSB of all our upcoming specifications
2. Making sure that all of the accessibility specs live within the LSB 
standard itself (and not in an "accessibility ghetto")
3. Making sure that accessibility is not perceived as "optional"
4. Releasing an AT-SPI standard soon while making sure that a D-Bus migration 
of AT-SPI is still possible
5. Checking whether the LSB would accept the idea to weaken the ABI guarantees 
for the AT-SPI case
6. Making sure that accessibility is kept in mind for other discussed topics 
such as multimedia.

The meeting went well; the LSB accepted all point 1-4 without problems. There 
were objections to 5, but we have been provided with an alternative way of 
reaching our goals.

Detailed summary:

Rules for the creation of LSB modules:
* The labelling of modules as "optional" will be replaced by more descriptive 
formulations such as "candidate ABI". ABI specified in non-mandatory "future 
candidate" modules must be on track to become mandatory in the next LSB 
* ABI specified in mandatory modules must be present in all major 
distributions (either in the current version, or in an upgrade scheduled for 
no more than a few months after the LSB release).
* FSG Accessibility is invited to also release non-ABI (functional) 
specifications as LSB modules (such as keyboard accessibility user interface, 

Status of D-Bus itself:
* There was agreement on D-Bus itself as "future candidate" in LSB 3.2, to 
become mandatory in LSB 4.0.

* LSB 3.2 freezes April 2007. This means mandatory ABI must be shipped in all 
relevant distributions by summer 2007, and "future candidate" ABI must be 
shipped in all relevant distributions by summer 2008.
* LSB 4.0 is scheduled for spring 2008. This means mandatory ABI must be 
shipped in all relevant distributions by summer 2008, and "future candidate" 
ABI must be shipped in all relevant distributions by summer 2009.
* We need to contact the distributions early enough to ensure that we meets 
these deadlines.

Accessibility (application side):
* The LSB already includes atk and QAccessible.
* Qt4 will become mandatory in LSB 3.2, so coverage on the application side 
will be complete on all LSB-conforming distributions.
* It was suggested that from a branding perspective, it is better to put the 
already standardised application side interfaces into the focus. We could 
stress that this allows distributions to ship interfaces and assistive 
technologies making use of those.

Accessibility (system and desktop):
* xkb is included. The LSB also invites us to release the functional (user 
interface) keyboard specification as an LSB module. KDE already implements 
the spec, so the timeline for this depends entirely on GNOME. We can include 
the functional spec in LSB 3.2 if a GNOME version supporting it is released 
by April 2007 and if we have confirmation from the relevant GNOME-based 
distributions that they will ship it by summer 2008.
* X extensions such as composite: I received the question how many 
applications are already using those.

Accessibility (client side):
* We had an extensive discussion that ruined our time schedule. There was 
unanimous agreement on virtually all points described below.
* There were strong objections to specifying two alternative ABIs for the 
distributions to pick from. Whenever two concurrent sets of ABI are 
specified, distributions need to ship them both. There were equally strong 
objections to making both CORBA-based ABI and D-Bus-based ABI mandatory. 
Including two concurrent sets of ABI is only done if in long-term 
perspective, there is very strong ISV market demand for keeping both of them 
alive and stable.
* There was unanimous agreement that we need to work towards a single, 
generally accepted client-side ABI for AT-SPI that works for both Qt and Gtk, 
and that the D-Bus approach looks like the best candidate for it.
* The LSB would rather include no AT-SPI ABI specs or tests at all (only the 
IDL itself) than do anything that might be perceived as a weakening of the 
long-term ABI stability guarantee  (especially since not a single single ISV 
is known to be targetting AT-SPI).
* The LSB welcomes us to create an LSB module for the AT-SPI IDL while leaving 
the exact ABI unspecified. If we do this, then we need to be very clear that 
the CORBA-based ABI derived from the IDL is not "candidate ABI" expected to 
become mandatory later. If add a link to a conformance test to the spec, then 
we also need to make it clear that the test is only meant as non-mandatory 
example, and that other implementations using their own tests are equally 
* The timeline for including AT-SPI as ABI depends entirely on the willingness 
of GNOME, KDE, Trolltech, IBM and the distributions to cooperate on a shared 
D-Bus-based implementation.

* I forwarded our requirement list to Real, who will make sure that it is kept 
in mind when discussing possible audio standards.


More information about the Accessibility mailing list