Inspector not seeing contents of UITableViewCell

[Jeffrey Blaze]

My native iOS app contains an edit page comprised of a number of UITableViewCell objects.  Inside of each is a UILabel object and a UITextField object.  Inspector does not see those nested objects - when I click on either of them, just the parent UITableViewCell is highlighted, and no info is displayed in the hierarchy columns.  When I record actions against the textField, Inspector generates code like this:

wd.findElement(By.name("(null)")).click();

wd.findElement(By.name("(null)")).sendKeys("My text");

On a related note, I have two other UITableView objects, each containing a number of UITableViewCell objects.  They contain UILabel objects, which Inspector does not see (again, highlighting of the parent only and nothing in the hierarchy columns).  

I have set the Xcode accessibility attribute for all possible objects.

I am new to Inspector, so please pardon me if there is some obvious setting I should have known about.

[Dan Cuellar]

Inspector displays what's returned by the appium server's page source command, perhaps page source is omitting the contents?

[Jeffrey Blaze]

Thanks Dan.  Nope, pageSource does not display them.  I also can't see them when recording an Instruments Automation script.

[zma...@gmail.com]

I have similar issue. How to solve it? Thanks.

[Dan Cuellar]

If you want elements to show up you can add accessibility ids to them in XCode.

// makes element accessible (if it's not by default)

[element setIsAccessibilityElement:YES];

// sets an id

[element setAccessibilityIdentifier:@"YOUR_ID"];

// makes children accessible

[element setAccessibilityElementsHidden:NO];

[Jeffrey Blaze]

I did set up accessibility in Interface Builder, but I did not try the setAccessibilityElementsHidden setting - I'll give it a shot.  Thanks Dan!

--
http://appium.io
---
You received this message because you are subscribed to a topic in the Google Groups "Appium-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/appium-discuss/TH1n7LIgMnM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to appium-discus...@googlegroups.com.
Visit this group at http://groups.google.com/group/appium-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeffrey Blaze]

Turns out that the default value of setAccessibilityElementsHidden is NO, and I had already set accessibility (in Interface Builder)  for the UITableViewCell.

I poked around the Apple doc a bit, and found the instructions below (here).  The gist of it is that you should turn accessibility off for the container object (in my case the UITableViewCell) and turn it on for the container contents (in my case a UILabel and a UITextField).  I did that, and it worked great - I have full visibility and control over those objects in Appium Inspector!  I also did it for another UITableViewCell that contains a UILabel and a UIDatePicker, and now I can see and manipulate the UIAPicker and UIAPickerWheel elements!

A couple gotchas:

-- The recorder in Instruments still does not seem to be able to see any deeper than the UITableViewCell objects

-- I found Appium Inspector to act a little funky.  After I configured the first UITableViewCell as above, Inspector acted as if I had configured the second one instead!  Only after configuring all UITableViewCell objects did Inspector deal with them correctly.

Enhance the Accessibility of Table Views

If your application displays a table view in which each cell contains items other than (or in addition to) text, there are a few things you can do to make it more accessible. Similarly, if your table view displays more than one piece of information per row, you can enhance a VoiceOver user’s experience by aggregating the information in a single, easy-to-understand label.

Note: If your table cells contain any of the standard table-view elements, such as the disclosure indicator, detail disclosure button, or delete control, you do not have to do anything to make these elements accessible. If, however, your table cells include other types of controls, such as a switch or a slider, you need to make sure that these elements are appropriately accessible.

If the table cells in your application contain a mix of different elements, determine whether users interact with each cell as a unit, or with individual elements inside the cell. If users need to access individual elements inside the cell, you should:

• Make each individual element accessible separately.

• Make sure the table cell itself is not accessible.

• Succinctly describe the overall contents of the cell and use this description for the label attribute of the cell. Note that, in this case, the label is considered to be one of the accessible elements within the cell.

You’ve probably recognized that a table cell that contains multiple items, such as text and controls, fits the criteria of a container view, as defined by the UI Accessibility programming interface. However, you do not have to identify the cell as a container view or implement any of the methods of the UIAccessibilityContainer protocol, because the table cell is automatically designated as a container.

If your table contains cells that provide information in discrete chunks, you should consider combining the information from these chunks in the label attribute. When you do this, VoiceOver users can get the meaning of the cell’s contents with one gesture, instead of having to access each piece of information separately.

A good example of how this can work is in the built-in Stocks application. Instead of providing the company name, current stock price, and change in price as separate strings, Stocks combines this information in the label, which might sound like this: “Apple Inc., $432.39, up 1.3%." Notice the commas in this label. When you combine discrete pieces of information in this way, you can use commas to tell VoiceOver to pause briefly between phrases, making it easier for users to understand the information.