UITableView/UITableViewCell custom accessibility with VoiceOver on iOS
UITableView/UITableViewCell custom accessibility with VoiceOver on iOS
- Subject: UITableView/UITableViewCell custom accessibility with VoiceOver on iOS
- From: Josh de Lioncourt <email@hidden>
- Date: Mon, 28 Oct 2013 19:38:27 -0400
I’ve seen posts in the archives here, as well as on StackOverflow, describing a number of problems with customizing accessibility for UITableView, and more particularly subclasses of UITableViewCell. I’ve seen these as, over the last few days, I fought my way through several of them, and more besides.
Below is a list of the problems I’ve discovered, workarounds that I’ve found, (if any), and an outstanding issue that I’m still experiencing. I’m hoping for any additional information/insights anyone here may have on these…especially better workarounds and/or a solution for the unresolved problem.
Subclassing UITableViewCell allows one to override accessibilityLabel to return custom text for the table row, instead of the default concatenation of labels from the cell’s subviews. This works as expected, but you have no access to capturing accessibility focus, or actions like accessibilityPerformMagicTap, etc.
- (NSString *) accessibilityLabel
{
return (@“This is a cell.”);
}
Problem #1 arises when your cell contains, for instance, controls which you which to be individually accessible to VoiceOver. Setting your UITableViewCell subclass to return NO for isAccessibilityElement, and setting accessibilityLabel to return nil, has no effect on this.
After much experimentation, it appears the UITableViewCell is doing a great deal of custom accessibility work, partly through the UIAccessibilityContainer protocol. As this is undocumented, save for the UIAccessibilityContainer protocol methods themselves, much of it is mysterious, aside from the fact that it appears to be returning objects that are of private classes, (ie. UIAccessibilityElementMockView).
If one overrides the UIAccessibilityContainer methods to return the elements you wish to be visible to VoiceOver, this somewhat works, but produces copious warnings to the console at runtime that Accessibility can’t find things it is looking for.
I finally was able to overcome this by overriding the UIAccessibilityContainer methods in such a way that it would appear that the custom elements you’re trying to get VoiceOver to see are inserted at indexes starting from 0, and that any items beyond that are retrieved from super and returned with indexes shifted up by the number of items you have inserted. In this way, both your custom elements and the private ones can be located by the system.
At this point, things are working, and include an added benefit that you can catch things like accessibilityPerformMagicTap within the subviews of the cell…something which flatly does not work otherwise.
The final, outstanding issue, is that once you have implemented all of this and everything works as you wish for VoiceOver, UIRefreshControl, which has been implemented as a subview of UITableView, no longer cooperates with VoiceOver. Performing a scroll gesture, (VoiceOver 3-finger-swipe-down), causes the refresh action to be triggered, regardless if you are at the top of the UITableView display or not. I’ve tried intercepting the accessibilityScroll at the cell level and redirecting it to various views, including the UIAccessibilityElementMockView, (which I’m retrieving from accessibilityElementAtIndex as simply UIAccessibilityElement to avoid using anything undocumented), but have been wholly unable to find anything that repairs the scrolling once custom accessibility elements are entered into the mix.
UIRefreshControl works perfectly, of course, if you don’t venture beyond accessibilityLabel for the table cells.
What I have gathered from the console warnings makes it look as if there’s a lot going on under the hood for UITableView and UITableViewCell in terms of accessibility, and trying to make individual components of cells accessible will either break things terribly, or are ugly workarounds that are likely to be broken at some point themselves.
I’d appreciate any additional insight on this from anyone here.
Thanks.
_______________________________________________
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