Re: Where does the accessibility hierarchy "start"?
Re: Where does the accessibility hierarchy "start"?
- Subject: Re: Where does the accessibility hierarchy "start"?
- From: Mike Engber <email@hidden>
- Date: Fri, 2 Jun 2006 10:00:28 -0700
Our app uses only Cocoa for top-level elements such as the window
and its main view. Everything else, and I mean everything, is
custom after that.
You will need to use subclasses for your Windows (or their Main view)
so you can override the children they report via the AXChildren
attribute. You will also need to override accessibilityHitTest and
accessibilityFocusedUIElement to report your objects (instead of
views or controls).
In theory, you shouldn't have to subclass NSApp - because it should
delegate stuff like hit testing and AXFocusedUIElement to the
appropriate window.
In practice, it looks like you may have to override NSApp so your can
override AXFocusedUIElement - I think your window's override of that
attribute will be circumvented. This is a bug - I'll file it.
I think that should cover most of the entry points into the default
hierarchy of NSObjects. By taking control of these choke points you
should be able to keep accessibility confined to your own hierarchy
of objects.
Take a good look at the ImageMapExample I referred to in my previous
email.
http://developer.apple.com/samplecode/Cocoa/idxAccessibility-date.html
It shows how to accessorize an object from scratch - which is much
trickier than modifying an already accessorized object (e.g. NSView).
-ME
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden