[Kde-accessibility] Re: [Issue N25746] Qt Accessibility

[Bill Haneman]

Hi Volker:

> as well; your documentation will certainly be a very good help here
> (the ATK documentation is a nightmare).

If you have specific suggestions regarding the ATK documentation they
are welcome.  We consider the ATK API documentation to be concise and
reasonably complete; however we are aware of the relative lack of
overview documentation.  The docs on the GNOME.org website are out of
date due to technical problems, but if you build ATK from cvs you should
get up-to-date documentation.

You may also find it helpful to review what Mozilla's accessibility
group has done with nsiAccessible has done to implement ATK, since the
Mozilla group has already done this; like QAccessible, nsiAccessible was
a MSAA-focussed implementation originally.

Like MSAA, ATK uses a hierarchical representation of UI components which
are then queried by clients for interfaces, so your comments below apply
to ATK as well.  The primary differences between the APIs are in the
richness/complexity of certain interfaces which ATK provides which MSAA
doesn't include.  Note that the Mac accessibility architecture, while
more complete than MSAA, also has a few holes in our opinion when
compared to ATK.

- Bill

> Note that the design behind QAccessibleInterface is very close to the
> COM interface of Microsoft's MSAA. The idea here is that the client
> only knows about objects of a certain "level", e.g. window handles. The
> client looking into a window has of course no idea that that window
> actually displays QListViewItems, so he cannot ask for anything for
> those items; this is why MSAA has a parent-child navigation API, and an
> interface either provides another interface for it's children (e.g.
> that's what the default implementation does, using Qt's object
> hierarchy), or provides the relevant information for the children
> itself (e.g. that's what the implementation of QAccessibleListView
> does). This way the accessibility client doesn't really have to care
> about object structures - he just asks the for the accessible interface
> for a given widget (at a given spot, which is easy to find for every
> accessible client), asks that interface if there is a child object at
> that spot, and then asks the interface for the relevant information
> about that child (child == 0 if it's the object itself).
> 
> All in all I came to the conclusion that the MSAA interface design is
> very well thought through and easy to implement and use both for the
> application (providing information) and for the client developer
> (requesting information), even though the interface is really too basic
> to be able to use it without falling back on the complementary
> technologies.
> 
> Cheers,
> Volker
> 
> --
> Volker Hilsheimer, Support Manager
> Trolltech AS, Waldemar Thranes gate 98, NO-0175 Oslo, Norway
> 
> _________________________________
> Trolltech tip:
> To explore how Qt applications can be made scriptable by using QSA,
> visit http://www.trolltech.com/products/qsa
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility