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: Daniel Jalkut <email@hidden>
- Date: Thu, 14 Jan 2010 13:45:34 -0500
Thanks for the info, James:
On Jan 14, 2010, at 1:10pm, James Dempsey wrote:
> There's really no good way to do this at present. On the other hand, having a region of a table view that a sighted user can see, but which is ignored by VoiceOver can lead to confusion in a collaborative environment (the sighted user sees N columns, but the VoiceOver user is told about only N-1 columns).
I actually have a few instances of "hacks" like this, and in the worst case scenario, there is really no discernable column, even to a sighted person. I.e. in one scenario I'm abusing a dummy table column to provide a slight indentation for visual aesthetics. Again, not defending this practice, just looking for how to provide the best possible accessibility in light of the current shenanigans.
As you may have noticed in my response to Christiaan, I did make some rough progress trying to fake out the column's dataCell with something that is particularly inaccessible. I provoked some scary looking inspector errors, so I backed off.
> Although, I realize it displays only transient status (might this be like a progress indicator of some sort? or a text status "Downloading..."?), if any of these operations can take more than a second or two, you may want to expose that cell as an AXProgressIndicator or AXBusyIndicator if it is a graphical progress indicator, or as an AXStaticText if it is text status.
Yes, it's a progress indicator, similar to what you would see in Mail while refreshing accounts. This whole problem stems out of the fact that NSProgressIndicator doesn't offer a cell counterpart, so everybody hacks this kind of visual feedback in their own special way, usually adding a progress view to the hierarchy dynamically. In this case my table column is merely a visual placeholder, while the progress indicator view gets installed into the view hierarchy transiently.
Mail.app avoids the problem of a dummy column, by using just one column but truncating the text within that column to suit a progress indicator when needed. But examining the progress indicator, it reveals they suffer their own accessibility compromises:
http://skitch.com/danielpunkass/nxq55/accessibility-inspector
It appears they are manipulating accesibility such that the progress indicator appears to be a direct descendant of the outline, but the parent relationship isn't reciprocated.
I guess longer term I'll look to see if I can fake the qualities of the associated progress indicator. If I can do that then it does seem to even make sense to have a separate column (or at least a separate cell) for the progress activity.
Thanks again,
Daniel
_______________________________________________
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