[Accessibility] Summary of the LSB accessibility discussion
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
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.
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
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
* 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