[Kde-accessibility] documentation of QAccessible and friends

[Bill Haneman]

On Sun, 2003-03-09 at 12:39, Volker Hilsheimer wrote:

> > 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)
> 
> For interface based development, which is sort of inevitable in
> component development IMHO, multiple inheritance is an extremely useful
> feature. 

Maybe your definition of multiple inheritance is different from mine. 
If you have interfaces, you don't need multiple inheritance at all,
since objects can inherit multiple interfaces without having to share a
common ancestor or implementation.  This is usually cited as a strength
of the interface model, since it avoids some of the well-known problems
of multiple inheritance.

> For accessibility, any accessible object becomes a component,
> and the accessibility APIs the component implements (ie. the interfaces
> it inherits from) tell the accessibility client what it can do with the
> component. If a component implements a selection interface, then the
> object in the application will most likely have a concept of selection.

I see; you are using the term "multiple inheritance" differently.  The
terminology which I find more familiar would say that components
"implement" multiple interfaces - but these components do _not_ inherit
from those interfaces.  Do you see the distinction?  I think that your
suggestion is "multiple interfaces", which is our approach as well.

>From the client-side of course these interfaces are used exactly as you
suggest, i.e. the interfaces have semantics that tell about the
capabilities of the object and indicate how that component can be
interacted with.

> > >
...

[Volker suggested that the needs of an accessible=text API could be
provided with rich text strings].
> >
...

> Considering that there will always be significantely more accessibility
> servers than accessibility clients it's important that implementing the
> server's side of accessibility is as easy as possible, and that the
> clients can handle different levels of "sophistication".

It should be as simple as possible - but no simpler :-)  
(Rich text is too simple.)

> If the client can use a specialized interface that gives more exact
> information about things like glyph bounds (which is probably irrelevant
> information for 90% of all AT clients) he can use it. But the client has
> to handle the situation where it is dealing with an accessibility server
> that has non implementation for such an interface. e.g. should be able
> to understand i.e. richtext markups, and use them to generate ie. a DOM
> tree that can be made "visible" to the user by whatever means necessary.

Glyph bounds are certainly not irrelevant for most AT clients, we have
found that they are essential for screenreaders and magnifiers, for
instance, which are two of the most important AT client types of all.
(Lack of this type of information is one of the issues that AT
developers have raised with MSAA, and a reason why they continue to
listen to lots of system API calls).  Remember that MSAA is intended as
a supplement to the existing win32 environment; if you need an
accessibility API that is 'complete' and which gives the client all it
needs to know without snooping display drivers, listening in on system
'text-out' calls, etc., you need more API.  You are probably aware that
uptake of MSAA among AT developers has been somewhat slow, this is one
reason why.  All the Windows ATs that I am aware of use MSAA strictly as
a supplement to the other, more invasive, system-snooping techniques. 
The AT clients of at-spi do not, they use a pure API approach.

As you have pointed out, interfaces are a good way to handle "different
levels of sophistication".  However our experience has been that all
textual objects need to implement all of AtkText, otherwise assistive
technologies simply cannot work properly.  In particular,
screen-review-mode screenreaders need all the glyph bounds info (as do
magnifiers).  In fact we are constantly adding to the list of components
that implement AtkText since we are finding that just exposing a 'name'
for objects isn't enough, even our buttons and frames need to implement
AtkText.

> > > 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.
> 
> Hm, for the Qt widgets the cursor position and the selection is entirely
> sufficient. It's in fact even entirely sufficient for the user, who
> cannot modify anything but cursor position and selection when he wants
> to insert, copy, paste or whatever. So if you have a property
> "cursorPosition", and a selection API, then you can do anything
> programatically what the user can do interactively.

Probably most of AtkEditabeText could be bridged to with such a system
(as long as text selection and child selection are separately handled in
QAccessible's selection API), but eventually you may run into noticeable
limitations.

> Not everything might be doable with a single string parameter of course,
> but named actions work very nicely in e.g. Qt's signals and slots, OLE
> automation, SOAP... you name it. I don't see why it should not work
> here, assuming that there is a way to pass parameters through e.g. a
> QValueList<QVariant> (since the parameters need to be marshalled a
> variant would be a rather obvious solution).
>
>
> > > 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.
> >
> 
> And here interfaces and multiple inheritance scale very well.
> 
> All in all I don't see any fundamental conflict here, so I will start
> looking into extending QAccessible with more interfaces for special
> requirements, and will have a look at ATK to see what sort of
> functionality seems to be required.
> 

Thanks, this would be very helpful.  I think the only known area of
disagreement seems to be AtkText, and I think we agree that some kind of
QAccessibleText should exist (but don't agree on its scope.)

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>