Eric et al.
I am back from two long business trips and I was finally able to get back to opening official Radar reports for the problems that I reported earlier on this list.
FYI, those radar reports are: 16569087 (item 3), 16581471 (item 4), 16602946 (item 5), and 16602964 (item 6). I would like to get back to items 1 and 2 (documentation and best practices) when those other items get addressed and get some official response (and, hopefully, fixes): Then I will be in a good position to follow up with recommendations for other developers on how to approach the accessibility of menu items with views right — currently the reported problems (esp. items 3-4) prevent achieving the full accessibility for the custom views in menu items, unfortunately.
Also, after some more experience and considerations around the current behavior of native menu items with custom views set for them, I have one suggestion:
I see that the native menu item is always a part of the tree of accessible UI elements. That is correct for the native menu items (with no views). But for a menu item with a view that does not look reasonable to me: When a view is set for a menu item, the menu item does put the full responsibility on the view for drawing (including highlighting) and handling any mouse interactions with the view. And the view is the only child object of the menu item in this case (in the accessibility UI element tree). Objects like controls, in such a case, simply “hide” (exclude) themselves from the AX tree, by returning NO in accessibilityIsIgnored. I think that the same approach is very feasible for menu items with views. Any objections to that from your side or specific reasons (other than historic) for not allowing that?
In case if my suggestion makes sense to you, I propose to eventually enhance NSMenuItem with the standard accessibilityIsIgnored method so that it can be reloaded in a child class. To ensure back compatibility, let the default implementation of NSMenuItem return YES, to reflect its current (historic) behavior. Alternatively, to make things easier for developers, NSMenuItem could be enhanced with a settable BOOL property (something like “accessibilityIgnored”) that could programmatically changed from its default YES to NO, when required, — then no need to create a custom child class just to change this aspect. And the menu class (NSMenu) plus the auxiliary class for the menu's faux UI element would also need to be enhanced to take that flag value into account when reporting the actual accessibility children and selected child to the accessibility clients in OS X.
Your comments and notes are welcome, as always. --- Vladimir CTO, Consultant and Developer
|