Hi Volker,

> ok, sorry about my wrong assumptions about the usability of MSAA. The
> reason we implemented is was that customers asked for it being
> supported, and at that time the Sun/Gnome efforts were at the point that
> the KDE discussion is now. We had - and still don't have - anybody who
> would have been familiar enough with accessibility from a user's or
> end-user-tool developer point of view, and were happy enough that we
> could wrap the rather cluttered MSAA interface into something nicer ;-)

Please don't take my comments as criticisms of the decisions you've made. 
Supporting MSAA will make a contribution to the accessibility of KDE/Qt
applications when running on Windows.  But I fear you will nontheless find
that you need to do one-on-one work with many of the individual AT vendors
to get them to support your applications (even though they are using MSAA!),
just as the Mozilla/Netscape Windows accessibility team is finding
presently.

> The idea behind our interface was to make it as easy as possible to
> implement them for the different controls and control subelements, and
> to leave it to the client to do something useful with this information
> (e.g. to rather provide the text contents of a browser with HTML tags
> and to leave it to the client to make them "visible" in a reasonable
> way), and I still think that this is - as a concept at least - a
> reasonable approach (assuming that there will be a significant number of
> applications developed by clueless developers that should provide
> accessibility information, and only a significantely smaller number of -
> highly specialized - accessibility tools developed by people with much
> clue about the issue).
> 
> The trick is now to provide as much information as possible, and to give
> the client as many ways to interact with the objects as possible. The
> infrastructure we have is IMHO flexible enough and should be easy to
> extend to allow a good mapping to ATK, AT-SPI, MSAA and whatever comes
> along on KDE.
> 
> We will try to put some resources into finding the "holes" in our API
> (e.g. the relationship API in ATK has no equivalent, while the selection
> handling has at least some etc.), and of course will hopefully receive
> feedback from you guys ;-)

We want to work with you, but our time commitment will likely be somewhat
constrained as our hands are very full getting what we have out the door. 
We'll do the best we can!  We've been interested in working with KDE/Qt from
the start of our work just over 2 years ago, and made an honest attempt to
be as lightly dependent on GNOME libraries in AT-SPI as possible in the
hopes that it could be a pan-UNIX layer.  Alas, at the time we didn't have
much successful engagement with the KDE/Qt community, and so I fear our work
in that regard may be less-than-perfect.  At each of the last two Linux
Accessibility Conferences (held in Los Angeles at the same time as the CSUN
Conference on Technology and Persons with Disabilities), we led discussions
on ways to interoperate with KDE/Qt.

I sincerely hope we can bridge KDE/Qt with the GNOME accessibility work. 
I've been in the disability technology industry for 11 years now, and the
work we are doing with UNIX accessibility is one of the most exciting
developments since folks at my previous company invented the
Off-Screen-Model technique in 1989 and provided the first blind access to a
graphical desktop.  To corroborate this, please see the report of Sun and
the GNOME community receiving the Helen Keller Achievement award from the
American Foundation for the Blind (their highest honor), at:
http://developer.gnome.org/projects/gap/news.html


Regards,


Peter Korn
Sun Accessibility team
_______________________________________________
kde-accessibility mailing list
kde-accessibility@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-accessibility