You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<h2class="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,
<spanstyle="visibility: hidden;">
hidden from all users,
<spanid=barstyle="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.
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:
It’s a hidden node
It’s not part of an aria-labelledby or aria-describedby traversal
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.
Given the following test case:
That case says the expected accessible name for that
h2
element isvisible 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 hiddenspan
.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:
So, when my code hits that
<span style="visibility: hidden;">
element, it finds that: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.
The text was updated successfully, but these errors were encountered: