Accessible name calc should allow aria-labelledby to reference aria-hidden

third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp

Index: third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
diff --git a/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp b/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
index 0e68691113381ecaef9955e8a2d8d8af865009b7..e27b54f495c82e0c75f2e48d521be16364cd9e35 100644
--- a/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
+++ b/third_party/WebKit/Source/modules/accessibility/AXNodeObject.cpp
@@ -1649,8 +1649,12 @@ String AXNodeObject::textFromDescendants(AXObjectSet& visited, bool recursive) c
         children.append(ownedChild);
 
     for (AXObject* child : children) {
-        // Skip hidden children
-        if (child->isInertOrAriaHidden())
+        // Don't recurse into children that are explicitly marked as aria-hidden.
+        // Note that we don't call isInertOrAriaHidden because that would return true
+        // if any ancestor is hidden, but we need to be able to compute the accessible
+        // name of object inside hidden subtrees (for example, if aria-labelledby points
+        // to an object that's hidden).
+        if (equalIgnoringCase(child->getAttribute(aria_hiddenAttr), "true"))
             continue;

[aboxhall, 2016/04/25 18:21:25]

Does this have any effect on <label> elements?

[dmazzoni, 2016/04/25 22:33:03]

Yes, it looks like it does. A label element with aria-hidden=true on it will now
be excluded from the accessibility tree but still used as part of the name
calculation for the form control it labels.

I added a new test to show this.

Does this seem reasonable or should I restrict the logic to only do this for
IDREFs like aria-labelledby and aria-describedby?

[aboxhall, 2016/04/25 22:43:42]

My understanding is that only aria-{labelledby, describedby} get this magic, per
2A. Since we already track inAriaLabelledByTraversal (hopefully that gets set
for aria-describedby as well - perhaps a single extra test for
aria-describedby?) it should be pretty straightforward to thread that through
here, I believe?

[dmazzoni, 2016/04/26 15:39:32]

Here's the text of 2A:

If the current node is hidden and is not referenced by aria-labelledby or
aria-describedby, nor referenced by a native host language text alternative
element or attribute, return the empty string.

That second part, "referenced by a native host language text alternative element
or attribute", covers things like <label> too.

I agree it's not clear but I checked with Bryan and Rich and they agreed with
that.

I think the only purpose of inAriaLabelledBy in our code should be to make sure
we don't keep following aria-labelledby more than once.

The visibility part is more straightforward and doesn't require keeping track of
it, rather when computing the accessible name of X, you don't worry about
whether X itself is visible or not (since you assume that if this function is
being called, the accessible name of X is interesting to someone). So you just
compute the accessible name of X, but when recursing into descendants you check
their visibility.

 
         // If we're going between two layoutObjects that are in separate LayoutBoxes, add