[Kde-accessibility] Re: Qt Accessibility

[Volker Hilsheimer]

> Hi Volker!
>
> It would be nice if you could have a look at some ideas regarding
> QAccessible* at http://accessibility.kde.org/developer/kdea11y.php
>
> Also, I have a question regarding the accessibility plug-ins: How do you
> provide plug-ins with QAccessibleInterface objects? There does not seem
> to be a documented API.
>
> Olaf.

Hello Olaf,

There is indeed no documented API for accessibility plugins right now. The
current infrastructure still uses QCom directly (the later deprecated API
introduced in the Qt 3.0 betas), which is also used in the internals of
e.g. custom widgets for Qt Designer, image format plugins or SQL drivers.
For those we have dedicated plugin classes that hide the nasty details,
e.g. QWidgetPlugin, but the concept is the same.

The code that turns a shared library into an accessibility plugin is in
QTDIR/plugins/src/accessible/widgets/main.cpp. A class implements a
factory interface, and provides a list of (widget) class names that it can
provide a QAccessibleInterface for (this class is the equivalent to a
QWidgetPlugin subclass in custom widgets for designer).

The plugins are then loaded and identified in qaccessible.cpp,
queryAccessibleInterface. The QPluginManager class looks for all shared
libraries exposing an interface of the type specified (ie. the
QAccessibleFactoryInterface), and collect the information about which
plugin provides which class name. That plugin is then asked to create the
QAccessibleInterface implementation.

queryAccessibleInterface is then called by Qt to respond to a request from
the AT client application (ie. WM_GETOBJECT on Windows).

Adding such functionality to QObject does not make much sense IMHO. For
most cases this function would return the null pointer, as most QObjects
are not supposed to be accessible in the first place (QTimer etc.). Having
this in QWidget would be a better idea, but would require a public API in
QWidget, which sort-of indicates that this function can be called
reasonably by anybody (which it can not, as providing such an object makes
only sense when answering the request).

What would probably make most sense is a way to install non-plugin-based
factories. This factory can then reside in the application binary rather
than in a separate plugin, which makes it easier to implement
QAccessibleInterface for custom widget. Moving the QAccessibleWidget
helper class into the Qt API will probably be a good idea.

What would be important for us to know is how Qt can communicate with the
AT-SPI bridge. How does the Qt application get notified that it is
supposed to provide a QAccessibleInterface, how does Qt pass that
QAccessibleInterface to the bridge library, and how does Qt pass
notifications on to the bridge.
As discussed on the web, a solution that introduces no dependencies to Qt
would obviously be the best. Hence I guess a shared library with a defined
name and C-API would be the best (since the bridge would only work on the
pure-virtual QAccessibleInterface it wouldn't even have to link against
Qt, and only bootstrap some classes used by the API, e.g. QString, QRect
and QMemArray; linking the bridge against Qt would however not be a
problem).

Qt could then try to dlopen that library when the first request comes in
through the event loop (at this point, QAccessible::isActive() returns
TRUE if the library could be loaded), and resolve two basic functions from
that shared library:

- ProvideAccessibleObject( QAccessibleInterface *iface, int requestID )
This function would be called to handle the request from the AT client.
The client request would most likely be sent to a Qt widget (since
initially only widgets are visible for the client) through a defined
QEvent (or any other message system Qt can handle through the event loop),
specifying a requestID to ensure synchronization with the response. Qt
calls QAccessible::queryAccessibleInterface(...) for the object that
received the message, gets a QAccessibleInterface from either a plugin or
a factory, and passes that QAccessibleInterface on to the bridge library,
which then bridges the API to AT-SPI.

- NotifyAccessibilityUpdate(QAccessible::Event, WinID window, int childID)
This function would be used in the Unix implementation of
QAccessible::updateAccessibility()

Does this make sense to you? Are more callbacks required to handle e.g.
IPC? Also note that Qt right now does not fire all possible events (ie.
ObjectShow, ObjectHide is never sent by Qt for widgets, as Windows does
that already). Is this something we should do for other platforms? Are the
Events, States and Roles etc. we have in QAccessible sufficient?

We will discuss the Qt Accessibility Architecture in Trolltech in a couple
of days (when 3.2 is out), I'll keep you in the loop.

Cheers,
Volker