Regarding test methodology, your current approach of using computedrole may not get you what you need. In theory, any of these implementations may have the element marked as "hidden" but have the backing object retain the role it would have if it were not hidden.... So these "expected role" tests as written could have both false positives and false negatives.

Another approach that may yield more consistent results between engines is to check the computedlabel of a rendered container element, that includes its label from contents. That container could have a mix of rendered or unrendered elements with mixed states of aria-hidden true and false.

As an example that may cause a failure in recent Safari builds at the moment (recently resolved in current WebKit source but not yet shipped, IIRC), since it implemented the original definition of aria-hidden=false, not the newest draft PR that the spec aligned on.

<h1 data-expectedlabel="one"><!-- not "one three" -->
  one <!-- part of the label in all implementations -->
  <span aria-hidden="true">
    two <!-- should not be part of the label in any implementation -->
    <span aria-hidden="false">
      three <!-- was part of the label in at least one older implementation before recent spec change proposal -->
    </span>
  </span>
</h1>

Likewise, aria-hidden=false should not be able to "undo" or "invert" the hidden-ness of a rendering style like display: none; or visibility: hidden;.

<h1 data-expectedlabel="one"><!-- not "one three" -->
  one <!-- part of the label in all implementations -->
  <span style="display: none;">
    two <!-- unrendered contents should not be part of the label in any implementation  -->
    <span aria-hidden="false">
      three <!-- aria-hidden=false should no longer be able to "unhide" an unrendered, hidden element, unless perhaps referenced in accname directly via aria-labelledby  -->
    </span>
  </span>
</h1>

Moving from test methodology to file naming, I'm not sure there is a good reason to have an overall states-and-properties dir, especially since some of the other features we're testing elsewhere (aria-label, aria-labelledby, etc.) are themselves properties.

I do agree that there could be a hidden or ignored directory with various files included... I expect there will be a lot more "hidden" or "ignored" tests once more test accessors are available.

Also, this file does not cover everything we'll want to determine about aria-hidden, so aria-hidden.html is too general a name, IMO. This might be renamed aria-hidden-tested-via-label.html or something more specific. Perhaps this file has a further logical split into two or more files.

Thank you @cookiecrook! Ready for another review.

these are both rendered fwiw

Is this note suggesting these new to-be-created tests be add to this file? If so, why? If not, I would remove this portion of the comment.

I don't think any of this first set can be tested reliably with label for the reasons listed in the first review. An implementation is not required to invalidate the label of a hidden element... The hidden rules can only be tested in how the element is incorporated into the label of a different element, like you've done in the next set.

Yes. Test like this, however I worry about a test requiring an explicitly empty label... It forces implementations to not be permissive in their allowance of "what the author probably intended."

Maybe we should remove this one, too. Or add in another part of the label outside the hidden span, or even a title attribute on the tested element.

👍

👍

I suggest removing or modifying this explicitly empty label test for the same reason listed above. Implementations should be allowed to work around author errors, when it results in an explicitly empty label.

If you see something in the AccName spec that disallows this, I'll file an issue, since:

• Users > Authors > Implementors > Spec Editors > Theoretical Purity.

Please use the real single pixel data URI image from the other accessibility tests. Gecko developers raised a bug with the other tests since their implementation is different if an image doesn't load.

I don't see these as being substantially different from the previous set. I would caution against exhaustive tests whose differences aren't really related to the core matter being tested. Doing so just makes the test data more difficult to maintain.

Ditto re: empty label above. Suggest modify or remove.