Accessing table view rows and general accessibility

[Eric Firestone]

GitHub user splisson opened a pull request to add a step for tapping a table view at a given index path. Currently, I'm not sure it's actually necessary, but I wanted to open the discussion.

First, I wanted to talk a little bit about the best practices for accessing a table view row. Using proper accessibility labels and values you should generally be able to achieve what you want, while making sure that your app is properly accessible for the visually impaired. Specifically, in our tests at Square, each row of the table view has an accessibility label which is the same and represents the type of object in the table (something like "Color") and an accessibility value which is distinct for each row (something like "Blue"). Then, we use the standard -stepToTapViewWithAccessibilityLabel:@"Color" value:@"Blue" to tap the desired row. This step already includes logic to scroll the desired row into view if necessary, and in fact, any offscreen element you try to tap will be scrolled into view if it's housed in a scroll view.

This is the preferred method because it makes the table properly accessible for the visually impaired. A table with now row accessibility labels, or with rows that all have the same label isn't very useful to a blind user. If, however, each row is uniquely identifiable via a label/value pair, then both KIF and a blind user should be able to find it without much trouble. If I'm missing a use case here where accessibility labels and values won't work or don't make sense, I'm open to adding something like splisson proposed.

Second, I wanted to talk a little bit about the philosophy of how KIF finds elements in the UI. In general, it does everything it can to imitate user interaction. This encourages good accessibility of your application, and helps check to make sure you're not missing anything. It also helps ensure that your tests aren't accessing functionality that a real user wouldn't be able to get to. That being said, some may want to get started more quickly, and may find the work of making their app properly accessibile too arduous. If enough people feel strongly, I'm open to having a "lazy" mode that's enabled by a compiler flag which would allow for steps that don't require proper accessibility.

Thoughts?

[Luis de la Rosa]

I agree that in all cases, having an accessibility label and value for
each table row/cell is good.

I think the problem is that sometimes you have dynamic data, either
location-based data or something like a timeline of tweets from
Twitter. In that case, it could be better to just tap on the first
row and proceed from there, since your app should probably let you do
some set of generic actions based on any location/tweet/dynamic piece
of data represented in a table row.

Otherwise, you would have to do something like:
1. Get the table via accessibility label
2. Read the accessibility value from the first row
3. Execute a KIF Test Step that taps on that row (view) with the pre-
determined label and the value from #2

So I think that pull request 57 is a good addition to KIF, with the
caveat that each table row/cell really should have an accessibility
label and value associated with it.

Luis

On Aug 9, 5:39 pm, Eric Firestone <firest...@squareup.com> wrote:
> GitHub user splisson opened a pull request<https://github.com/square/KIF/pull/57>to add a step for tapping a table view at a given index path. Currently, I'm

[Jim Puls]

On further discussion last week, we realized that this covers an important case where you have many more table rows than will fit on the screen. UITableView will lazy-load them, so accessibility is a non-starter.

We're planning on taking the pull request, but we're waiting on some stylistic changes as outlined in the request comments first.

-> jp

[jonahgabriel]

Here is something that I put together to help with a similar issue
where I needed to find and tap on a row in the bottom of a table view
with many cells...not sure if this helps with the discussion, but I
thought I would throw it out there:

+ (id)stepToScrollToViewWithAccessibilityLabel:(UIWindow *)inWindow
accessibilityLabel:(NSString *)inLabel scrollViewTag:
(NSInteger)inScrolViewTag
{
KIFTestStep *scrollStep = nil;

scrollStep = [KIFTestStep stepWithDescription:@"Scroll to view"
executionBlock:^(KIFTestStep *step, NSError **error)
{
UIView *taggedView = [inWindow viewWithTag:
99999];
if( [taggedView isKindOfClass:[UIScrollView
class]] )
{
NSError *labelError;
UIScrollView *scrollView = (UIScrollView
*)taggedView;
NSInteger yOffset =
scrollView.contentOffset.y;
CGRect scrollFrame = scrollView.frame;
CGSize contentSize = scrollView.contentSize;
while ( yOffset < contentSize.height )
{
UIAccessibilityElement *element = [self
accessibilityElementWithLabel:inLabel accessibilityValue:nil
tappable:NO traits:UIAccessibilityTraitNone error:&labelError];

if( element != nil )
{
break;
}

yOffset += scrollFrame.size.height;
CGRect scrollToRect = scrollFrame;
scrollToRect.origin.y = yOffset;
[scrollView
scrollRectToVisible:scrollToRect animated:YES];
}
}
return KIFTestStepResultSuccess;
}];



return scrollStep;
}

+ (NSArray *)stepsToScrollAndTapViewWithAccessibilityLabel:(UIWindow
*)inWindow accessibilityLabel:(NSString *)inLabel scrollViewTag:
(NSInteger)inScrolViewTag
{
NSMutableArray *steps = [NSMutableArray array];

[steps addObject:[KIFTestStep
stepToScrollToViewWithAccessibilityLabel:inWindow
accessibilityLabel:inLabel scrollViewTag:inScrolViewTag]];
[steps addObject:[KIFTestStep
stepToTapViewWithAccessibilityLabel:inLabel]];

return steps;

[Sébastien PLISSON]

Committed teh changes and added them to the pull request

-seb

On Aug 18, 12:03 pm, Jim Puls <p...@squareup.com> wrote:

[Sébastien PLISSON]

Changes committed in pull request

-seb

On Aug 18, 12:03 pm, Jim Puls <p...@squareup.com> wrote: