A button can't be found when within the header view of a table view

[justinseanmartin]

I have a screen with a button that can't be found within a table view. The reason is because it is failing the check for -accessibilityAncestorPreventsPresenceInAccessibilityHierarchy. However, I have a view where the UITableView is showing up as being an accessibility element, so the UIButton that is being filtered out by Subliminal.

I want to see if there are any issues with this change being compatible with existing tests. It seems to fix my problem at least in this case.

[justinseanmartin]

At least in my case, it looks like in our case, the TableView contains a View, which eventually down the tree has a label in a child view. The TableView is picking this up as its accessibilityLabel and being marked automatically as accessible. This is preventing a Button that is also under the same View from being found, because it is the child of an accessible element.

[wearhere]

Can you add a test case to SLElementMatchingTest, @justinseanmartin? That would help me envision what you're talking about and would also of course help verify the fix.

[justinseanmartin]

Added a test case using a storyboard, as that was the easiest way to reproduce our exact setup. It is a bit strange, but we have:

UITableView 
  -> UIView 
    -> UIButton (accessible = true)
    -> UIButton (accessible = true)
    -> UIView
      -> UIView
        -> UILabel (accessible = true)
        -> UILabel (accessible = true)

There are no UITableViewCells in the hierarchy (yes, odd, but we have our reasons). In this case, the UITableView is being marked as accessible from the UILabel, which is preventing the UIButton from being accessible.

I also believe the UILabels should be accessible directly (as SLStaticText), as they are appearing in the UIA hierarchy from logElementTree. I haven't debugged yet, but my fix doesn't make that case work.

[justinseanmartin]

Updated for feedback from @wearhere

[wearhere]

After much consternation and consultation with @justinseanmartin, I believe I have a more minimal fix:

diff --git a/Sources/Classes/UIAutomation/User Interface Elements/NSObject+SLAccessibilityHierarchy.m b/Sources/Classes/UIAutomation/User Interface Elements/NSObject+SLAccessibilityHierarchy.m
index 7240566..e7b4eb7 100644
--- a/Sources/Classes/UIAutomation/User Interface Elements/NSObject+SLAccessibilityHierarchy.m  
+++ b/Sources/Classes/UIAutomation/User Interface Elements/NSObject+SLAccessibilityHierarchy.m  
@@ -179,14 +179,18 @@
 - (BOOL)accessibilityAncestorPreventsPresenceInAccessibilityHierarchy {
     // An object will not appear in the accessibility hierarchy
     // if an ancestor is an accessibility element.
-    id parent = [self slAccessibilityParent];
+    id parent = [self slAccessibilityParent], child = self;
     while (parent) {
-        // There are some cases where the UITableView will make itself isAccessibleElement, despite
-        // having accessible children that can be accessed in the hierarchy. For an example, see
-        // testMatchingButtonWithinTableView.
-        if ([parent isAccessibilityElement] && !([parent isKindOfClass:[UITableView class]])) {
-            return YES;
+        if ([parent isAccessibilityElement]) {
+            // Although `UITableView` makes an exception (as always):
+            // objects within its header or footer views may appear in the hierarchy.
+            if (!([parent isKindOfClass:[UITableView class]] &&
+                  (child == ((UITableView *)parent).tableHeaderView ||
+                   child == ((UITableView *)parent).tableFooterView))) {
+                return YES;
+            }
         }
+        child = parent;
         parent = [parent slAccessibilityParent];
     }

The name for the test case/storyboard would then become something like "testMatchingElementsWithinTableHeaderView". Phew!

[wearhere]

👌