We've covered this before on the list. So you might want to go back and re-read some of my previous emails.
When the NSApp's accessibilityHitTest is going to find the window at the specified point then call accessibilityHitTest on that window which will use NSView's hitTest method to find the view at the specified point.
The call to NSView's hitTest will defeat you. It will poke into your view hierarchy.
You would normally prevent this by overriding accessibilityHitTest on the window containing your view. But, I don't see how you can do this as an imbedded view without resorting to some major hackery.
Alternatively, accessibilityHitTest will ultimately be called on the view the window finds. So, if you override accessibilityHitTest for _every_ view in your view hierarchy you could take control that way. I.e. the view can return some other ui element from its accessibilityHitTest method. But, obviously, this requires you to use custom subclasses for _everything_ in your view hierarchy. This might be impossible if some of the views in there are not created by you. E.g. an NSBrowser will create subviews.
This is the first issue that comes to mind, but there may be other problems as well depending on the details of your actual view hierarchy vs the accessibility hierarchy you want to present.
-ME