How much information is needed? I'm learning about atk as I go here, so some feedback on what exactly you want exposed would be helpful.

My initial review is that our current canvas (GooCanvas) implements some Atk features. For example, each canvas item exposes an atk.Object and an atk.Componenent. We can set a name and a description on these items, so Orca/Accerciser will be able to tell what items are in in each sync group.

Accerciser could only see changes to the canvas if i close and restart Accerciser. From reading every ATK reference I found and the canvas source code, i'm pretty sure this is because the GooCanvas ATK code doesn't seem to implement the children-changed signal.

I'm not confident of being able to patch GooCanvas and get a new stable release of it out in time for Conduit/GNOME 2.24 so I began to look at how I can improve the situation locally in Conduit without needing to patch GooCanvas. 

I had hoped to subclass the GooCanvas accessiblity object, but its not bound to python so I can't.

I am considering rewriting the GooCanvas accessiblity support in python locally (and temporarily). I'm currently unable to find an example of where the atk python bindings have been used as extensively as I would need to to do this. I'm not even sure how you are supposed to implement a GInterface in python, subclassing them doesnt seem to be enough - at least according to, gobject.type_interface. The GtkTreeModel interface seems to have a helper written in C to allow python to implement custom tree models, so maybe you can't implement a GInterface in python. So this avenue is also blocked, for the moment.

At this point, the most I am able to do without patching GooCanvas and/or some major help from pygtk experts is use atk to set name/description properties on the existing accessible objects and to define relationships between the canvas items with atk.Relation.

Feedback appreciated.

(In reply to comment #1)
> How much information is needed? I'm learning about atk as I go here, so some
> feedback on what exactly you want exposed would be helpful.

Thank you for your care and consideration -- it is refreshing and much appreciated!

In general, we're going to look for things along the following lines:

1) Can one interact with the UI from the keyboard alone?  Unplug your mouse.  Are you able to efficiently accomplish the tasks your GUI is supposed to let you do?  If not, you might have some keyboard navigation work to do.

2) Does theming work -- try the high contrast large print inverse theme.  Does your GUI adapt completely?  If not, you might have some theming work to do.

3) From the ATK standpoint:

   a) If your component is basically doing the same thing as another
      GTK+ component, consider ditching your custom component and
      using the GTK+ component.  A lot of work has gone into making
      the GTK+ components accessible.

   b) If your component is presenting text to the user, can it be 
      obtained programatically via the AT-SPI?  Use the 'accerciser' 
      application to drill down to your component and find out.
      If not, you might need to implement the Accessibility_Text
      interface.  You might also be able to get away with setting
      just the accessible name.

   c) If your component is presenting an image to the user, can a
      textual equivalent be obtained?  This could be just an accessible
      name.   Again, use 'accerciser' to help out.  Also consider 
      setting up tooltips for the component so that the user can bring
      them up and hide them via Ctrl+F1.

I think that should cover *most* of the cases.  There's also a bunch more to consider, such as setting the appropriate accessible state and exposing accessible actions, but the above tends to cover most of the problems we run into.  Note that when setting the accessible name, you should mark the string for translation since it is going to end up being presented to users.  Try also to use a short descriptive name just as you would for something like a push button (e.g., "OK", "Cancel", "Synchronize").

We might actually depend on #377642 for this.

And I think we definitely depend on bug #546341

I think get_n_children and ref_child are also needed. When applications tell AT there is a new child, AT will get the child from these functions. For the child, get_parent and get_index_in_parent are needed. ref_state_set is needed for both parent and child. And as Will said, for particular item, interfaces maybe needed, like text interface for text item.

To register the accessibility type, a corresponding factory type is needed. libgnomecanvas would be a good example. If you want to take a look at the code, please apply patch for bug #469482 first.

I copied the GnomeCanvas accessibility code for GooCanvas, so it should be almost as accessible as GnomeCanvas (though I did that a while back so it is slightly
out of date, e.g. it doesn't have the a11y support for text items).

Does GnomeCanvas emit "children-changed" anywhere? I can't see it.

Conduit is not under active development anymore, has not seen code changes for eight years, and saw its last tarball release in 2010.
Its codebase has been archived: https://gitlab.gnome.org/Archive/conduit/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.