Re: How to hide a table view column from Accessibility hierarchy?
Re: How to hide a table view column from Accessibility hierarchy?
- Subject: Re: How to hide a table view column from Accessibility hierarchy?
- From: Mike Engber <email@hidden>
- Date: Fri, 15 Jan 2010 10:03:31 -0800
On Jan 14, 2010, at 5:12 PM, Christiaan Hofman wrote:
If what you say can be true, then the implementation is buggy. The
documentation clearly says that elements returning YES from
accessibilityIsIgnored should themselves be ignored as children, hit-
testing, and focused element. Their children may be returned, but
not the elements themselves.
I'll make a final attempt to explain this...
<quote>
When asking for an object’s children, ignored children should not be
included; instead, the ignored children should be replaced by their
own unignored children. The same applies when asking for an object’s
parent: an ignored parent should be skipped and the first unignored
ancestor treated as the real parent. Likewise, when a hit-test or
focus test is satisfied by an ignored element, the element’s first
unignored ancestor (or descendant in certain cases, such as single-
celled controls) should be used instead.
</quote>
This is correct. It means that your implementation of the
accessibility protocol should be carful to never return ignored UI
Elements. Functions like NSAccessibilityUnignoredChildren are designed
to make this easier to do.
It's true that ignored elements should never be returned (and if one
is, that's a bug). But, that's not relevant to my point.
I'm saying that if you suddenly make some UI element ignored, it might
cause the wrong element (or no element) to be returned.
Ergo when there are no children, they are essentially pruned from
the hierarchy. Or at least, they should be. So when anything you say
happens in practice, either the implementation is buggy, or the
documentation is buggy. It's as clear as can be.
This does not follow.
I think the confusion might be due to the fact that there are two
hierarchies - there's the hierarchy of UI elements that assistive apps
see - which never contains any ignored UI elements. Then there's the
hierarchy of Cocoa objects that work to together to create the other
hierarchy - by implementing the accessibility protocol.
Making an object ignored simply means it should not be exposed in the
assistive app hierarchy. The object is still part of the Cocoa
hierarchy and must still correctly implement the accessibility protocol.
E.g. let's say you subclass some cell so that it's now ignored. If
that cell is, in fact, currently focussed, then
accessibilityFocusedUIElement will be called on it (to give it a
chance to return any child UI Elements it has). It must return
something sensible. Whether it has any children or not has no bearing
on this.
You've created your own subclass, ensuring the accessibility protocol
is still implemented properly is your responsibility. There is no
expectation that the standard Cocoa widgets support having their
ignored switch flipped - note there is no setAccessibilityIsIgnored
method.
Being ignored has a very specific meaning - and it's not the same as
being hidden.
-ME
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden