On Sep 1, 2016, at 4:44 PM, Pete Brunet < email@hidden> wrote:
What is the proper way to handle hidden controls? On Win the way this is
done is to remove the showing and visible states, but leave the control
in the tree.
For Mac I don't see states to convey the showing/visible states? Is
there such a means? Or is the proper approach to remove the control
from the a11y tree?
Or is there a third approach that should be used?
That's an interesting question. I would have thought you should leave them in the tree but set the appropriate accessibility attribute. However, I don't see an accessibility 'hidden' attribute for UI elements generally. If there were one, then for standard Cocoa UI elements that can be hidden, the appropriate accessibility attribute should be set and unset for you automatically in accordance with standard Cocoa principles. See generally Apple's Accessibility Programming Guide for OS X.
In the NSAccessibility protocol (OS X v10.10), you find the accessibilityHidden property, but the documentation says it is only for the application. It is settable, and you have the NSAccessibilityApplicationHiddenNotification to let observers know when the application becomes hidden. You have the accessibilityVisibleColumns property and others like it for the hidden or unhidden state of a table's or outline's columns, rows and cells. You have the accessibilityAlternateUIVisible property for a slightly different purpose, to identify the state of elements that switch between a standard and an alternate UI apperance. The accessibilityShownMenu property also serves a slightly different purpose. The accessibilityVisibleChildren property gives you convenient access to children who are in the tree and who are visible in a different sense (not scrolled out of view, for example). WebKit has its own 'hidden' property for HTML5 content using the ARIA standard.
In the older NSAccessibility informal protocol, you have the NSAccessibilityHiddenAttribute for the application's visibility.
Developers can certainly show and hide any UI element. That is handled by NSView's 'hidden' property, which is settable, and its 'hiddenOrHasHiddenAncestor' read-only property. And you have the -viewDidHide and -viewDidUnhide methods to learn when it happens. See the "Hiding Views" section of Apple's View Programming Guide. But the accessibility API doesn't seem to have a way to deal with that if a developer does it.
I recall that a general principle of Mac application design was, long ago, that Apple applications should not show and hide UI elements indiscriminately, with only a few exceptions like table and outline columns, rows and cells. In the early days, this was because of a profoundly held belief that the Mac should be easy to use, which isn't possible if there are lots of controls sitting around that are invisible to the user. But in recent releases of Mac OS X, that principle has been largely abandoned, and Mac applications are now full of controls that are invisible but suddenly pop into view when you pass the cursor over them. It constantly confuses beginners, and even experts when they start using a new application for the first time. But there you have it, somebody decided that invisible controls make sense now for the Mac -- or at least they're pretty. That's what the new accessibilityAlternateUIVisible attribute was invented to handle, at least for the case where a UI element changes its appearance when you move the cursor over it. Perhaps the answer to your question is that invisibility should now be considered an alternate UI, and you should use the accessibilityAlternateUIVisible attribute to identify it.
It would be helpful to hear from Apple about this.
|