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: Christiaan Hofman <email@hidden>
- Date: Fri, 15 Jan 2010 19:20:05 +0100
On Jan 15, 2010, at 19:03, Mike Engber wrote:
> 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
>
I think your confusion is an that you're talking about suddenly making an element ignored. I'm not saying that, I'm talking about elements that ARE ignored (i.e. accessibilityIsIgnored ALWAYS returns YES). Therefore in all your statements, the condition for your if's is not satisfied, therefore the rest of your statements are irrelevant. Or at least should be.
Christiaan
_______________________________________________
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