[Kde-accessibility] Fwd: KDE 3.1 suggestion: gtkeyboard clone

[Bill Haneman]

On Thu, 2002-06-27 at 10:06, Navindra Umanee wrote:
> Peter Korn <peter.korn@sun.com> wrote:
> > It is this second set of rich, dynamic functionality that present will NOT
> > work on KDE or X apps, as those apps do not implement the accessibility API. 
> > At such point as that were to change, however...
> 
> That was very informative, thank you.  Another question:
> 
> Why is it necessary to have an explicit accessibility API at all?
> Can't this be made transparent to the developer?  I mean, does someone
> programming a GNOME app really want to worry about a whole new API, on
> top of all those other libs?  I guess the situation is sort of similar
> to i18n and that it isn't actually that painful...

Navindra:

The need for an accessibility API from the assistive technology
perspective should be fairly clear; the API (or, rather, as we call it
in this case, the "SPI", or Service Provider Interface) provides
assistive technologies with a consistent source of information about
running user interfaces, via some IPC mechanism.  IPC is required since
assistive technologies generally run in their own process space, and
need access to all the applications on the desktop.

As for the application-side API, having an API does not mean that the
application developer must take action to use it.  An API is required in
order to support accessibility features and services on the UI
components, but the developer need not use this API directly; just as a
developer who uses an internationalized toolkit need not know about CTL
and input methods in order to get i18n-compatible software, a developer
who wants to create accessibility-friendly applications need not write
directly to an accessibility API; the API support should be built into
the UI components.  

In the case of GNOME and GTK+, a developer who uses stock GTK+
components in standard ways incorporates accessibility support into his
or her applications because the "ATK" accessibility support is built
into the widget set and UI toolkit.  Our goal was for this to be as
transparent to developers as possible, and in this case a developer need
not call any special API at all or even be aware of the API in order for
it to be available in applications.

That said, we believe strongly that developers _should_ be aware of
accessibility needs just as developers should be aware of
internationalization, because otherwise developers can inadvertently do
things that impair the builtin support for those features which a
toolkit may provide, by making assumptions based on a subset of users
who, for instance, read and write English or use a Roman character set
or write left-to-right or can see and/or use a mouse, etc.  Though the
ATK accessibility APIs don't require developer action in order to be
activated and present, developers _can_ write directly to those APIs in
selected places in their applications, and in so doing can greatly
improve the quality of the resulting accessibility support.

The idea is that if developers use the UI tools in "ordinary" ways, a
reasonable level of accessibility support comes "for free", but that
application developers can easily improve that support by adding a few
lines of explicit accessibility API calls to their applications.

As Peter infers, our architecture was also designed to accommodate
various UI toolkits and APIs, and is thus not entirely GNOME-centric. 
For instance, Java applications are integrated into our "SPI" via
bridging code, so assistive technologies like GOK can offer the same
rich accessibility support for Java/Swing applications that they offer
GTK+ and GNOME applications.  Work is also underway to provide this
support for Mozilla and the StarOffice/OpenOffice.org office suite, and
integration of other UI toolkits is also under discussion.  Integrating
KDE/Qt into the mix has been discussed before, and only awaits suitable
committment of engineering resources, volunteer or otherwise.

In the meantime, GOK is kind of a special case since it can provide
useful keyboard emulation for applications that don't yet have explicit
accessibility support; that's not technically feasible for many/most
other assistive technologies.

best regards,

Bill

> -N.
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility