On Feb 22, 2007, at 3:54 PM, Ricky Sharp wrote:
My application has its own custom UI and all my controls/cells/etc are fully accessible.
Some screen layouts make use of one or more nested tabless tabviews for structure purposes. The hierarchy can thus be a bit deep in places and when doing things like GUI scripting, you have things such as:
set value of UI element "Maximum sum" of group 1 of group 1 of group 1 of window "Settings" to 15
I'm considering going down one of two paths:
(1) Add a category to NSTabView and implement accessibilityIsIgnored to return NO.
(2) Subclass NSTabView and provide my accessibility overrides against that class.
I'm currently leaning a bit towards (2) since it seems cleaner. Also, this could give me the flexibility in adding a 'flag' ivar as to whether or not to include the group in the hierarchy.
For example, the middle 'group 1' tabview happens to contain all controls that make up addition problem settings. Thus, I could drop some of the groups out and just include one to help organize thing a bit.
So, if dropping all, I would have:
set value of UI element "Maximum sum" of window "Settings" to 15
Or, if dropping all but one, I could have:
set value of UI element "Maximum sum" of group "Addition settings" of window "Settings" to 15.
To my knowledge, every UI element would have a unique title and thus no collisions would occur if referring by name. Thus, I really don't need any of the groups to disambiguate contained controls.
How have others dealt with the accessibility of tabless tabviews? Can you spot any pitfalls in the above approaches?
Thanks,
Is the scriptability of the application an important piece of functionality for your users - or perhaps you are using UI Scripting more for automated testing of the app?
Note that an assistive app can register for a value changed notification when the contents of the tab change - so, an assistive app could be relying on that notification to realize that it needs to refresh the children of the tab view.
Each assistive app can determine what it wishes to report. For instance, VoiceOver does not generally speak groups to the user, or focus on them. However, again, an assistive app could be perfectly aware the element is there, just not dealing with it.
UI Scripting is, of course, a pretty direct mapping of the accessibility hierarchy which leads you to the 'group 1 of group 1 of..." scripts. As a rule, and in this case, I wouldn't sacrifice the general accessibility of the app to try to make for less verbose UI Scripting.
-James