Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[accname] The spec as written for computing accessible names doesn’t result in traversing into hidden subtrees to find “un-hidden” child nodes #248

Open
sideshowbarker opened this issue Nov 27, 2024 · 0 comments
Assignees

Comments

@sideshowbarker
Copy link
Member

Given the following test case:

<h2
  class="ex"
  data-testname="heading with name from content, containing element that is visibility:hidden with nested content that is visibility:visible"
  data-expectedlabel="visible to all users, un-hidden for all users"
>
  visible to all users,
  <span style="visibility: hidden;">
    hidden from all users,
    <span id=bar style="visibility: visible;">un-hidden for all users</span>
  </span>
</h2>

That case says the expected accessible name for that h2 element is visible to all users, un-hidden for all users — that is, the text content of the first text node, but also the text content of that “un-hidden” span that’s nested inside a hidden span.

Now, looking at the spec steps at https://w3c.github.io/accname/#computation-steps, the first step in the algorithm after the “initialization” step is this:

A. Hidden Not Referenced: If the current node is hidden and is:

i. Not part of an aria-labelledby or aria-describedby traversal, where the node directly referenced by that relation was hidden.
ii. Nor part of a native host language text alternative element (e.g. label in HTML) or attribute traversal, where the root of that traversal was hidden.

Return the empty string.

So, when my code hits that <span style="visibility: hidden;"> element, it finds that:

  1. It’s a hidden node
  2. It’s not part of an aria-labelledby or aria-describedby traversal
  3. Nor part of a native host language text alternative element

And therefore, I return the empty string for it, and stop there.

More specifically, I don’t descend any further into the subtree for that <span style="visibility: hidden;"> element — because the spec doesn’t tell me to do that. Instead the spec just says, “Return the empty string”. And there’s nothing else in the algorithm that tells me to do anything with the child nodes of that un-referenced <span style="visibility: hidden;"> element.

In other words, there’s no way per-spec that I can ever get to that <span id=bar style="visibility: visible;"> “un-hidden” child node, in order to evaluate if it’s “un-hidden”.

Link to the version of the specification or documentation you were looking at at.

https://w3c.github.io/accname/#computation-steps

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? Yes.

@jnurthen jnurthen transferred this issue from w3c/aria Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants