Add accname tests for “Hidden not referenced” step

[adampage]

Closes web-platform-tests/interop-accessibility#32

[adampage]

Just getting my feet wet here. Could I trouble you for some initial thoughts, @cookiecrook?

These failures related to content-visibility: hidden and aria-hidden="true" make me wonder if I’m misunderstanding the accname spec, or if additional language is needed to handle elements that meet the spec’s definition of “hidden” but that also remain focusable? (related: w3c/aria#1856)

[cookiecrook]

[error]We stopped hearing from agent Hosted Agent. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610
Agent: Hosted Agent
Started: Today at 10:31 PM

Well, at least that explains why there are no results for WebKit.

[cookiecrook]

I thought of another example: the collapsed (hidden) contents of summay/details, when a role is applied that gets namefrom contents.

<summary role="comment" data-expectedlabel="visible contents" data-testname="namefrom:contents(comment role) on summary w/ hidden details" class="ex">
  visible contents
  <details>hidden contents</details>
</summary>

[adampage]

I thought of another example: the collapsed (hidden) contents of summay/details, when a role is applied that gets namefrom contents.

<summary role="comment" data-expectedlabel="visible contents" data-testname="namefrom:contents(comment role) on summary w/ hidden details" class="ex">
  visible contents
  <details>hidden contents</details>
</summary>

My brain broke on this one. 😅 First of all, <details> should enclose <summary> here, right? Not the other way around? And then the intention is to test the accessible name of the nested summary when it’s given an explicit role allowing name form contents?

[adampage]

Hey @cookiecrook, thanks again for your patience, for your feedback, and for all the test case suggestions. With the exception of the <summary role="comment"> one, I believe I’m all caught up, so I went ahead and resolved your previous comments.

In the case of aria-hidden="false" elements nested within aria-hidden="true", it seems neither Chrome nor Safari succesfully un-hide the nested content, which appears to put them in conformance with both ARIA 1.2 and the current editor’s draft, but I also see there’s still ongoing conversation in ARIA #1256. In any case, I left these WPT tests aspirationally expecting that aria-hidden="true" will in fact re-expose that content to the accessibility tree.

One weird behavior I noticed is that one of the two failing cases — #8 — actually does appear to kind of work in reality, at least when testing in macOS with VoiceOver (for both Chrome and Safari). When I move the virtual cursor to the rendered heading, I do get the expected announcement of “visible to all users, un-hidden for all users”. In Chrome, the devtools accessiblity tree shows both intended StaticText nodes as exposed, but then it also shows the parent heading as having an accessible name matching just the first node:

So that makes me suspicious that perhaps there’s a bug/feature in VoiceOver where it announces the full contents of the heading on focus of the virtual cursor, rather than the computed accessible name? As more interesting evidence, the rotor identifies the heading by the computed accessible name:

I’ll plan to do a little more testing of that in Windows to see how JAWS and NVDA behave.

[cookiecrook]

First of all, <details> should enclose <summary> here, right? Not the other way around? And then the intention is to test the accessible name of the nested summary when it’s given an explicit role allowing name form contents?

Yes, sorry. I think this markup is right now, but I'm no longer sure of the expectation.

<details role="comment" data-expectedlabel="visible contents" data-testname="namefrom:contents(comment role) on summary w/ hidden details" class="ex">
  <summary> visible contents </summary>
  hidden contents
</details>

Hmm… I'm no longer sure the above is expected, because I think it'd be reasonable for implementations to not provide a backing accessibility node for <details> itself when only the <summary> is displayed. Probably just add a todo comment.

[cookiecrook]

I left these WPT tests aspirationally expecting that aria-hidden="true" will in fact re-expose that content to the accessibility tree.

Since it's still ambiguous, we should probably comment those tests, with a link to the blocking spec issue.

[cookiecrook]

that makes me suspicious that perhaps there’s a bug/feature in VoiceOver

Do you have a permanent link to that test case? I can write up a bug and start to determine if it's an engine problem or a VO problem.

[cookiecrook]

Tests look good overall... Thanks for all your hard work on this one!

Minor nits below about testname and label names for clarity and permalink longevity.

[adampage]

Do you have a permanent link to that test case? I can write up a bug and start to determine if it's an engine problem or a VO problem.

@cookiecrook well, my premise with this test case was that an element with visibility:visible should be expected to override an ancestor’s visibility:hidden and surgically re-expose its own contents to the accessibility tree. But now I’m failing to find any spec’d documentation in either ARIA or CSS to support that expectation.

Our 1.3 editors draft doesn’t seem to make any exceptions for descendants of an element with visibility:hidden:

Elements, including their descendent elements, that have host language semantics specifying that the element is not displayed, such as CSS display:none, visibility:hidden, or the HTML hidden attribute.

But as far as interop goes, it does seem like there’s a test case here worth pursuing, since Firefox passes the test case (as written) while Chrome fails and Safari fails.

A strict reading of that language in the ARIA 1.3 spec suggests that I should keep the test case but change the expected label to “visible to all users,”, then file a Mozilla bug?

[adampage]

@cookiecrook besides this last comment, I believe I’ve addressed all your feedback with my latest batch of commits. Please let me know what you think?

[cookiecrook]

Approving either way, but with a minor preference for removing the commented code.

[cookiecrook]

I know you worked hard on these, but I think it would be better to check in the patch without the commented code, and only add specific examples once the new issue came to resolution... Otherwise someone might see 1256 is resolved (in the future) and uncomment these even if they don't align with the resolution… Or also bad, these could just sit around commented indefinitely.

[cookiecrook]

maybe just keep your test names, since they should be clear enough to show what needs to be tested? such as:

<!-- 
  Todo: once https://github.com/w3c/aria/issues/1256 resolved.

  - button labelled by an element that is aria-hidden=true which contains a nested child that is aria-hidden=false 
  - test name 2
  - test name 3
  - etc.
-->

[cookiecrook]

thanks for working so hard on these!

[cookiecrook]

Acknowledging that August James asked you to comment them, and October James asked you to remove them, so I won't stop you from squash merging as-is... Take your pick. Thanks.

[adampage]

Ha ha, no trouble at all, @cookiecrook — happy for the opportunity to contribute at all. I went ahead and removed the test cases that are blocked by aria#1256 but left a comment identifying each one by name. 👍🏻

Based on our quick conversation in the WPT meeting, I also left the expectation as is for the ...visibility:hidden with nested content that is visibility:visible test case, so Firefox is currently the only pass for that one.