[Kde-accessibility] documentation of QAccessible and friends

[Bill Haneman]

I have some comments, please see below:

On Fri, 2003-03-07 at 22:58, Volker Hilsheimer wrote:
...
> QAccessibleInterface is a generic API that abstracts every accessible
> "object" using four central concepts:
> 
> - an object is part of an object hierarchy. It can have children, and
> can have a parent
> This implies that the parent can identify any child with an index, so
> that you can navigate throught the complete hierarchy once you got hold
> of any object in the tree.

ATK of course has this same concept.

> - an object has properties
> Most properties can be expressed by strings - those properties can
> change. Some properties can only have a predefined value, e.g. values
> that an accessible client and hence a user relying on such a client can
> make use of, and are usually static, or at least not writable from
> outside. "role" and "state" are such properties.

ATK has this concept, except properties are read-write at the ATK level
but are generally presented to clients as read-only.

> - an object has methods
> You can push a button. IAccessible - and hence the current
> QAccessibleInterface API - only provide one default method, apart from
> "secondary" methods like setFocus. A new text property, e.g. "verbs" or
> "actions", that returns a comma separated list of strings, and a new
> method "doVerb" or "doAction" that takes that string is definitely
> something we can add to QAccessibleInterface, or to a new interface that
> would be supported using multiple inheritance until we can break binary
> compatibility in 4.0.

ATK doesn't use multiple inheritance, but it does allow multiple
interfaces to be implemented by the same object instance.  As noted ATK
supports multiple actions now.  I believe the Mozilla team dealt with
this by introducing extensions to nsiAccessible (which is a similar
class to QAccessible)

>
> - an object can change, and send a notification about this change
> That's what updateAccessibility is all about.

So far, this is virtually identical conceptually to ATK (and for that
matter, to the Java Accessibility APIs which predate MSAA and ATK).

> Microsoft figured out that those four central concepts might be
> sufficient to abstract any user interface object, but that it's
> impractical to both implement and use only those central concepts to do
> something complex like selection handling. So
> IAccessible/QAccessibleInterface has some special APIs for selection
> handling.

ATK has AtkSelection (for container/child selection handling) and
AtkText has some text-selection API.

> The AtkText API is pretty involved, and for QAccessible we would create
> a new interface that would be implemented only for a few widget classes.
> But then why not just pass the (rich)text string to the client, and let
> the client deal with it? It's definitely more efficient to pass the
> string to the client, and the clients figures out which character is at
> position X than making a remote procedure call to ask the server for
> that rather obvious piece of information. Same for attributes at
> position X.

Volker, I don't understand your suggestion (or at least, I don't see how
it could work).  If by "client" we mean assistive technology (AT
client), then the client cannot determine glyph bounds, etc. from rich
text.  Only the application/widget set (which in this case functions as
the "server") knows this information.  You just cannot get the necessary
information by passing some sort of marked-up string to the client; and
it's especially inefficient if the text objects are large,
content-wise.  The API approach is designed to get away from the concept
of AT clients with enormous caches that duplicate what's already in the
applications.

> Most of the AtkEditableText class could be put into a single function
> "doAction(const QString&)" - start_pos and end_pos would be handled with
> the selection API. doAction would by default use QObject introspection
> and check if there is a slot with that name, e.g. QTextEdit::paste()
> would be called if you call doAction("paste") on an interface that wraps
> a QTextEdit.

I think that a single string-based function API is really not sufficient
for EditableText; there are methods that take different types and
numbers of parameters, etc.  In general, in=process string-based APIs
are more trouble than they are worth.  No need for me to elaborate on
their drawbacks here, I am sure.  Our experience has been that text
editing and selection aren't nearly as tightly coupled as you are
suggesting.

> 
> There would be a few special interfaces that 90% of controls or objects
> don't have to take care about, e.g. for tables or - even worse -
> canvases.

Right, fortunately only a few components need complex APIs like
AtkTable.  But for those that do, it is really essential for good
accessibility information client-side.

Best regards,

Bill

> Volker
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility
-- 
Bill Haneman <bill.haneman@sun.com>