On 21 Apr 2008, at 8:27 PM, James Dempsey wrote: On Apr 21, 2008, at 10:38 AM, Christiaan Hofman wrote: So then the question is: how can I work around this problem and make it work? I have a custom view that advertises a StaticText role, for which I want to make subelement of the text accessible, such as links in the text.
Is your custom view is a subclass of NSTextView? No, it's a direct subclass of NSView. The only thing I know about it is the class name and that it implements NSAccessibility. If it were, I wouldn't have to ask my question.
As for the main text, it already implements full support for the (parametrized) attributes for StaticText. This is also the reason why I cannot change the role to Group, because I really don't want to reimplement this (as this is a huge task, as you say).
I'm still a little unclear on the class hierarchy. It sounds as if it is either: NSView : "BlackBoxViewClass" : "YourViewClass", or NSView : BlackBoxViewClass. (If it is the latter case, I'm not sure how you are changing the role - are you using a category)?
It's basically only StaticTextBlackBoxView. The full view hierarchy is something like PublicView : NSScrollView : NSClipView : BlackBoxView : StaticTextBlackBoxView. But the other views are not relevant to my question. Only NSScrollView and StaticTextBlackBoxView are accessible, the rest is ignored. PublicView controls everything and contains the data, BlackBoxView only draws a background, and StaticTextBlackBoxView displays the content (text, 'children', etc) and implements NSAccessibility. PublicView creates the whole view hierarchy when it's created, and there's no control over this process.
I'm overriding the relevant NSAccessibility methods using method swizzling on the StaticTextBlackBoxView class, as that's the only thing I can do. Since the parameterized attributes are already fully implemented on this "black box" class, it also makes me a little suspicious that perhaps there is an NSTextView, NSTextField, or NSTextFieldCell involved somewhere - perhaps unbeknownst to you, but regardless.
Definitely not. It's just a direct subclass of NSView. There is just some (attributed) string in the data displayed in the view. I do get the impression that the accessibility implementation of the text is pretty basic though. Also note that it's not editable in any way. If the parameterized attributes are already working in your superclass, I believe you can get this to work by adding attributes to the attributed string you return from the AXAttributedStringForRange parameterized attribute.
The attribute is NSAccessibilityLinkTextAttribute, and the value of the attribute should be the appropriate child element that you already have created. The attribute should be added to the range of text that has the link.
So, either you will need to override AXAttributedStringForRange, take the outgoing attributed and add the attribute and link element to the appropriate range, or if you can't override, you will reimplement that parameterized attribute to do the same thing.
You will also want to update AXRTFForRange to do the same thing.
Usually NSTextArea takes the link and does this, but in this case you will need to do this manually. I haven't tested this approach myself, please let us know if it works for you.
-James
No, the children I want to expose are not (necessarily) properties of the text. They are separate existing objects that are displayed on top of the text, but are currently not exposed at all for accessibility. Notice that I used the link only as an example. In fact I have an example where a "link" object is overlayed on an empty part of the view (pretty nasty indeed)!
Christiaan
|