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 02:12:15 +0100
On Jan 15, 2010, at 2:02, Mike Engber wrote:
> Let me say this again, ignored UI elements are _not_ the same as hidden UI elements. The fact that a UI element doesn't have any children does not change what it means to be an ignored UI element.
>
> On Jan 14, 2010, at 2:39 PM, Christiaan Hofman wrote:
>>> The only bullet proof way to hide a UI Element is to:
>>>
>>> - make sure its parent excludes it from its children
>>> - hit testing doesn't report it
>>> - focus testing doesn't report it
>>> - ensure it not returned by any other attributes (e.g. titleUIElement, ...)
>>>
>>
>> None of this should be relevant, because ignored elements should NEVER be returned by any of these. If some other element does this, the implementation is buggy. Defensive programming is not supposed t be a requirement (even if it is a good idea).
>
> Ignored elements won't be returned by any of these - but that doesn't mean the correct thing will happen.
>
> Specifically, even you've decided to override accessibilityIsIgnored you still have to ensure your object still properly implements the accessibility protocol - accessibilityHitTest & accessibilityFocusedUIElement might be called on your element and you still have to make sure they return the correct thing.
>
> The point I was making is that this is not always easy to do. Returning the next unignored ancestor (what usually happens by default) is often correct, but not always.
>
>
>>> Currently, this is not easy to do because:
>>>
>>> - Excluding from the parent's children might require subclassing the parent which can sometimes be problematic.
>>>
>>
>> No, it should work out-of=the-box, otherwise there's a bug you could report to Apple.
>
> It should not be expected that having a UI element return itself as ignored is a way to hide it. That's not what ignored means. You might be able to get away with using it that way in some circumstances, but it's not what it's designed for.
>
> As I said before, currently, the only proper way to hide a UI element is to keep it out of the UI element hierarchy.
>
> -ME
>
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.
<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>
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.
That said, the fact is that the implementation is buggy.
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