[Kde-accessibility] Fwd: KDE Accessibility

[Daniel Molkentin]

Here is the reply from Trolltech.

Have fun,
  Daniel

----------  On Wednesday 27 November 2002 15:25, Volker Hilsheimer wrote:  
----------

Subject: KDE Accessibility
Date: Wed, 27 Nov 2002 15:25:21 +0100
From: "Volker Hilsheimer" <vohi@trolltech.com>
To: <molkentin@kde.org>

Hi Daniel,

I'm the author of the accessibility support in Qt, and Matthias
forwarded me your summary of the first meeting.

One of the issues mentioned that the Qt API for accessibility support
was not versatile enough to be used by KDE, and that the implementation
we have would need to be extended (and implemented on UNIX). Well, here
is some infrastructure overview (from a Windows perspective), since the
documentation of the Qt stuff is rather thin this might give some
insight:

On Windows, an application is queried by accessibility clients (like a
magnifier or screen reader) for the accessibility interface (COM
interface IAccessible) for a specific object. This is done via a window
message WM_GETOBJECT to a window handle.

- Qt receives the WM_GETOBJECT message
Qt uses the static function QAccessible::queryAccessibleInterface(
QObject*, QAccessibleInterface ** ) to get hold of the accessibility
implementation for the widget that the WM_GETOBJECT message had been
sent to.
queryAccessibleInterface is cross platform - it loads the plugins that
implement the factory interface, figures out which plugins implements a
accessibility factory for the widget class in question (and goes up the
class hierarchy if there is no plugin for that specific widget class, so
MyPushButton:public QPushButton will get the accessibility
implementation for QPushButton), and asks the factory for an interface
to that implementation. The implementation and factory stuff is also all
cross platform, and in a plugin that is part of Qt.

- If Qt receives a interface pointer it creates a Windows specific
wrapper around the cross platform interface implementation (the Qt
accessibility interface is "easier" than IAccessible, but just as
powerful), and uses Windows magic to return some integer value to the
accessibility client (the WM_GETOBJECT message contains some information
important for the Active Accessibility infrastructure which is used
here). The accessibility client receives the pointer, and calls the
functions via RPC (since IAccessible is a COM interface COM does all the
magic for that).

- Additionally to that, Active Accessibility provides a notification
mechanism that allows applications to tell accessibility clients that
something important has changed or happend (e.g. a checkbox changed it's
state). The static QAccessible::updateAccessibility() is provided for
that, and a large set of "event types" (e.g. ValueChanged) is defined in
an enum (the enum values are identical to the respective values in
Windows, but can easily be mapped to something else).


Since Active Accessibility has been around for a while and is the
standard and obviously approved infrastructure around on a lot of
Windows desktops I would assume that the flexibility it offers is
sufficient (so the interface we have in Qt is sufficient - it is even
more flexible). If it is not sufficient it is trivial to add another
interface and implement that as well in the plugins (e.g. right now we
only have one default action, and can execute that action, but we could
implement an interface that returns the list of public slots (without
parameters), and that executes any of those slots etc).

Implementing the communication layer between the accessibility client
and the "server" is where CORBA - or whatever middleware - enters the
scene. All you/we have to implement is a way for the accessibility
client to ask for the interface to a widget, to call function of that
interface, and to do something useful with the results. And maybe you
could use the QAccessibleInterface directly without a wrapper
implementation.
Any RPC will do for that, and we would definitely be interested in
putting some efforts into this (e.g. implement the server side for the
RPC in Qt). Naturally, we would prefer this to be independent of e.g.
CORBA ;-)

The second platform dependent part is the notification mechanism, which
is trivial enough.

Well, please fwd. this to the respective lists/people. I would of course
like to know more details about what parts seem to be insufficient or
not flexible enough, so that we can add some fu in Qt. At least the
implementations we provide for all the Qt widgets should be reusable.

Cheers,
Volker

PS: And somebody should do something about the HTML of your webpage -
it's somehow misformatted with IE and Mozialla ;-)

-------------------------------------------------------