I'm going to respond to you off list with some more questions - but
I think to bootstrap you need your custom accessibility object to
hook into the existing accessibility hierarchy in the Cocoa app.
So you will need to override some of the accessibility methods in
the view that the rendering is done in.
In the containing view override accessibilityAttributeValue:, and
if the attribute value is NSAccessibilityChildrenAttribute, then
you will want to return an array of your custom UI elements (or the
top level custom UI element, if there is a root object).
In addition, you will want to override the hit and focus testing
methods:
in the view to call the same method in the appropriate child. It
would be OK if the content view had one accessibility child, which
represented the "AXWebArea". If that were the case, then in the
content view, you would simply call the hit and testing methods in
the accessibility child.
Yes, this is how it currently works:
Our main view forwards all accessibility* calls down to a "main"
accessibility root object that will respond on behalf of the view.
All queries for AXChildren, AXParent, etc on the main view, is taken
care of by the mozRootAccessible object. From that, you can get the
whole accessible hierarchy of objects, that will correspond to the
XUL interface.
Here's another related question:
Sometimes, but not always, the main view has a few subviews. The
subviews correspond to XUL widgets that might be *far* down in the
real ordered hierarchy. For example, due to technical details that
are too boring to go through here, plug-ins on webpages are a certain
NSView subclass, and so are context menus.
So I'm a bit worried that 3rd party accessible apps peek at the
NSView hierarchy to traverse the accessibility hierarchy. In my case
that would be fatal, because the view hierarchy is *not* ordered in
any sensible way, according to how the actual UI works.
