![[LWN Logo]](/images/lcorner.png) |
|
![[LWN.net]](/images/Included.png) |
From: kde-devel-request@max.tat.physik.uni-tuebingen.de
To: kde-devel@max.tat.physik.uni-tuebingen.de
Subject: Kde-devel digest, Vol 1 #1791 - 5 msgs
Date: Mon, 21 May 2001 12:45:05 -0500
Date: Sat, 19 May 2001 18:25:46 -0700 (PDT)
From: JP S-C <jp_sc@yahoo.com>
Subject: Feedback/help requested on accessibility project
To: kde-core-devel@kde.org, kde-devel@kde.org, kde-look@kde.org,
kde-usability@kde.org, kde-accessibility@master.kde.org,
qt-interest@trolltech.com
Reply-To: kde-devel@kde.org
--0-1350490027-990321946=:18804
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Dear All,
I and many members of the Linux accessibility
community believe the first thing that needs to be
done is to make certain types of information contained
in GUI's built in Qt easily available outside to
outside appliactions. This type of information
includes (but is not limited to) the name, placement,
type, state, and properties of a widget and its
relation to other widgets in the application. Once
this sort of infromation can be easily obtained from
external processes it will be possible to write a
Qt/KDE screen reader (or preferably a Qt module for a
multi-toolkit X windows screen reader, manifiers, or a
piece of software that outputs information contained
in Qt apps to Braille terminals. Once this big first
step is attained, minor modifications to KDE UI's may
be made to make it easier for visually impaired or
otherwise disabled users to function more effectively
in KDE.
The way in which Java, MS, and (new on the scene) GTK+
accessibility have made or are making the
above-mentioned widget or GUI information accessible
is through an API. This makes is possible for all
applications written with the toolkit to remain
untchanged and for all the work to reside in the
screen reader.
Bill Haneman, a core member of the GNOME Accessibility
Project and employee of Sun Microsystems (which made
the Java Accessibility Api or JAA,
www.sun.com/access/), has come up with a cross toolkit
framework for making this UI information externally
available. The framework is called the Adaptive
Technology Service Provider Interface -- AT SPI. The
"service" part refers to accessibility services,
namely revealing UI information through an API.
Attached are the initial AT SPI interfaces "...
specified in IDL, though we plan to provide them as C
bindings to a shared object library when implemented,
and expect that most adaptive technologies will choose
to use those C bindings." (Source: Bill Haneman,
original e-mail included below).
The AT SPI needs feedback (and eventual
implementation) from Qt/KDE developers. One future
discussion (perhaps to be had on the FDAWG mailing
list, www.speechinfo.org/fdawg)might be the use of
CORBA, which is currently being strongly considered by
those designing the SPI.
For a basic introduction of adaptive technology
(technology for the disabled) that explains things
like screen readers and the different types of
disabilities go to the GNOME Accessibility Project
(http://developer.gnome.org/projects/gap/).
Sorry my last e-mail about Qt/KDE accessibility
through SPI was slightly unclear. Any feedback and
help would be appreciated (if you are interested in
doing so, consider joining the Free Desktop
Accessibility Working Group, FDAWG mailing list,
www.speechinfo.org/fdawg, or the kde-accessibility
mailing
list,http://master.kde.org/mailman/listinfo/kde-accessibility).
Thanks so much.
Best,
--JP Schnapper-Casteras
Organizer of the Linux Accessibility Conference
Founder and Co-Admin of Project Ocularis
Free Desktop Accessibility Working Group --
www.speechinfo.org/fdwag
Founder of the kde-accessibility mailing list
Included Message from Bill Haneman:
Date: Tue, 08 May 2001 20:30:14 +0100
From: bill.haneman@sun.com
To: fdawg@speechinfo.org,
gnome-accessibility-list@gnome.org
Subject: Gnome AT Service Provider Interface, 0.1
Hello listees:
Some of you may already be aware of current work on
the Gnome Accessibility Project, and the fact that the
first version of the
Accessibility ToolKit (ATK) interfaces have now been
placed in Gnome cvs. Implementation of these
interfaces for the GTK+ UI toolkit has
begun and is also available via gnome cvs, project
"gail" (Gnome Accessibility Implementation Library).
[For those who are interested, we have two test
programs which use these interfaces to demonstrate
them in action, email me]
ATK describes a set of interfaces intended to be
implemented by or on behalf of UI components. These
interfaces describe the accessibility support at the
toolkit level, and allow applications to explicitly
provide accessibility information for their components
while providing a useful level of accessibility
support "out of the box" (that is, without the need to
modify the applications).
In order to export this toolkit-level accessibility
information to clients such as adaptive technologies
which run outside of the applications' process space,
and in order to provide accessibility information in a
toolkit-independent manner, we also must define and
implement a set of common interfaces which constitute
an accessibility "service". We call this service the
Adaptive Technology Service Provider Interface, or the
"AT SPI".
It is hoped that this interface will provide a toolkit
independent means for Unix-based adaptive
technologies, such as screen readers and screen
magnifiers, to get accessibility information from
running applications. Furthermore, it is our
intension that the AT SPI be a one-stop shop for
adaptive technology; i.e., ATs should not need to
install special hooks or hacks to get at the
information which they require, apart from the
services provided by the ATSPI.
We attach our initial draft of AT SPI interface
definitions. These interfaces are specified in IDL,
though we plan to provide them as C bindings to a
shared object library when implemented, and expect
that most adaptive technologies will choose to use
those C bindings.
Since our use cases include situations in which AT and
application may reside on different hosts, and since
our accessibility model is object-based, the best
candidate technology for IPC/component model
implementation appears to be CORBA. We believe that
this should be transparent to clients of the SPI, and
we intend to allow for alternate implementations of
these interfaces in the future. However it is likely
that all applications and toolkits which intend to
interoperate with respect to accessibility will need
to share the same IPC implementation protocol in the
near term.
We need your feedback. Is there functionality which
we have missed which needs to be included in the
accessibility interfaces? Is there functionality
typically exposed through the window manager which
needs to be made accessible to ATs? Are there
additional hooks or services which would be useful or
esential to the proper functioning of ATs that we have
not included here?
Lastly, since our hope is for transparent
interoperability with as many toolkits and unix
desktop platforms as possible, we'd like to note that
there are several layers at which toolkits can "plug
into" the "Gnome" accessibility architecture.
Toolkits which need an expedient solution and which
don't mind linking (possibly via an optional
dynamically loaded module) to glib can implement ATK
interfaces directly, and reuse the Gnome
application-side service implementation directly. In
this case both toolkit and adaptive technology would
be agnostic regarding the internals of the SPI
implementation. Other toolkits may wish to implement
the SPI interfaces themselves (Java will most likely
use this approach). We would like to work with
maintainers of other toolkits to ensure maximum
reusability and interoperability of the code being
written for the Gnome accessibility project.
For a block diagram showing how apps, ATs, and the SPI
relate to process spaces, please see
http://developer.gnome.org/projects/gap/SPIBlockDiagram.png
Best regards,
Bill
Attachments: SPI-0.1-IDL.tar.gz : interface
(Ed. Note: Tar file removed)
definitions
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland
=====
-
Cell Phone - 206-849-9032
Time Zone - Pacific (-08:00 UTC)
Home Page - http://ocularis.sourceforge.net
_______________________________________________
Kde-devel mailing list
Kde-devel@master.kde.org
http://master.kde.org/mailman/listinfo/kde-devel
End of Kde-devel Digest