4

Specify behavior when following a hidden subtree via aria-labelledby … by jaragu...

 1 year ago
source link: https://github.com/jaragunde/accname/pull/1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Specify behavior when following a hidden subtree via aria-labelledby … #1

Conversation

Owner

…or -describedby.

This describes more accurately the actual behavior of Firefox and Blink. There is a fundamental difference between those two yet, Firefox does not hidden aria-hidden nodes while Blink does. My preference would be to use aria-hidden to allow authors to explicitly hide content if they really want but I wouldn't push hard for it.

About WebKit, its behavior changes depending on how nodes were hidden, visibility:hidden and display:none seem to have different behaviors which suggests to have followed the innerText implementation, maybe sharing code.

Owner

Author

TODO: specify the possibility to use aria-hidden=true to explicitly hide a bit of the hidden subtree.

index.html

Outdated

<p>By default, <a class="termref">assistive technologies</a> do not relay hidden information, but an author can explicitly override that and include hidden text as part of the <a class="termref">accessible name</a> or <a class="termref">accessible description</a> by using <code>aria-labelledby</code> or <code>aria-describedby</code>. </p>

</details></div>

<div><details>

<summary>Example:</summary>

Owner

Author

These examples are new, too.

index.html

Outdated

</pre>

</details></div>

</li>

<li id="step2A.ii">If the <code>current node</code> has the <code>aria-hidden</code> property set to true, return the empty string.

Owner

Author

This clause, with the example below, are the only remaining additions to the text.

index.html

Outdated

</details></div>

<li id="step2A">

<ol>

<li id="step2A.i">If the <code>current node</code> is <strong>not</strong> <a href="https://html.spec.whatwg.org/multipage/rendering.html#being-rendered">being rendered</a> <strong>and is</strong>:

Owner

Author

In the line above, I'm replacing the use of "hidden" with "not being rendered", like James Nurthen had proposed here.

…or -describedby.

This describes more accurately the actual behavior of Firefox and Blink. There is a fundamental difference between those two yet, Firefox does not hidden aria-hidden

Nit: does not hidden -> does not hide

nodes while Blink does. My preference would be to use aria-hidden to allow authors to explicitly hide content if they really > want but I wouldn't push hard for it.

We should mention there are a few possibilities:

  1. Always remove aria-hidden content from any name calculation (even if pointed to by a relation). This is a relatively simply rule to explain and remember. It is not very helpful in the repair cases for aria-hidden, though, e.g. when someone puts aria-hidden on the body.
  2. Use the same rules for aria-hidden as other types of hidden. IOW use if part of a subtree that was hidden at the root, for any type of hidden. This is probably the simplest to explain and remember because all types of hidden become equivalent. This does not solve the tooltip case where the author wants to consistently remove part of the tooltip from the name, and the main tooltip goes in and out of being rendered.
  3. Only remove aria-hidden content in descendant subtrees of a labelledby or describedby, or if it's not in a labelledby/describedby calc. This solves the tooltip case, but is very hard to explain and remember.

After writing all of these out, I'm starting to get a preference for w3c#2. I think the tooltip case with some hidden content is contrived. The author can just remove those nodes. It's not worth creating the mess of w3c#3. And #1 has the issue for repair situations. WDYT?

About WebKit, its behavior changes depending on how nodes were hidden, visibility:hidden and display:none seem to have different behaviors which suggests to have followed the innerText implementation, maybe sharing code.

We should add this line at the bottom:
Closes w3c#57

@aleventhal aleventhal

left a comment

Good start. I added some thoughts. LMK what you think.

index.html

Outdated Show resolved

index.html

Outdated Show resolved

index.html

Outdated Show resolved

index.html

Outdated Show resolved

Owner

Author

We should mention there are a few possibilities:

  1. Always remove aria-hidden content from any name calculation...
  2. Use the same rules for aria-hidden as other types of hidden...
  3. Only remove aria-hidden content in descendant subtrees...

I'm changing my mind and I'd go with 2 right now. It should make the text easier to write and understand, and that's very important in an already complicated spec.

The kind of authors who care about the scenario we would solve in option 3 are probably already implementing it in a way that works with 2 (remove the node), because that's the way Firefox has always worked.

I'll give a try at how the text would look like.
@@ -0,0 +1,2 @@

<p>Indicates that the <a href="#dfn-element" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-element-4">element</a> is not visible, <a href="#dfn-perceivable" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-perceivable-3">perceivable</a>, or interactive to <em>any</em> user. An element is considered <em>hidden</em> if it or any one of its ancestor elements is not rendered or is explicitly hidden.</p>

<p>This definition includes elements <a href="https://html.spec.whatwg.org/multipage/rendering.html#being-rendered">not being rendered</a>, which don't have an associated layout box, or rendered with a <a href="https://drafts.csswg.org/css-cascade/#computed-value" data-x-internal="computed-value">computed value</a> of <a href="https://drafts.csswg.org/css2/#propdef-visibility" data-x-internal="'visibility'">'visibility'</a> different from 'visible', or hidden from assistive technologies using the <a href="https://www.w3.org/TR/wai-aria-1.2/#aria-hidden">aria-hidden</a> state.</p>

Owner

Author

The definition of hidden is from WAI-ARIA, I'm copying it here so we can discuss.

The second paragraph is new, it specifies the different kinds of hidden referencing other definitions and other specs too. I'm using the innerText spec as a source for some this text, because it explains the difference between display:none and visibility:hidden in an "spec-y" way.

Update in b2cfbb8: we discard proposing changes to WAI-ARIA definition of hidden.

<li id="step2A">If the <code>current node</code> is <a class="termref">hidden</a> <strong>and is not</strong> directly referenced by <code>aria-labelledby</code> or <code>aria-describedby</code>, nor directly referenced by a native host language text alternative <a class="termref">element</a> (e.g. <code>label</code> in HTML) or <a class="termref">attribute</a>, return the empty string.

<li id="step2A">If the <code>current node</code> is <a class="termref">hidden</a> <strong>and is</strong>:

<ul>

<li><strong>Not</strong> part of an <code>aria-labelledby</code> or <code>aria-describedby</code> traversal, where the node directy referenced by that relation was hidden.</li>

Owner

Author

This replaces the existing "current node is hidden and is not directly referenced by aria-labelledby..." text with something that explicitly includes its children.

index.html

Outdated

@@ -272,6 +293,9 @@ <h4>Computation steps</h4>

</ol>

</li>

</ul>

<div><details>

<summary>Comment:</summary>

<p>The result of <a href="#step2B.ii.b">step 2B.ii.b<a> in combination with <a href="#step2A">step 2A<a> means that <a class="termref">user agents</a> MUST include any hidden nodes as part of the <a class="termref">accessible name</a> or <a class="termref">accessible description</a> when traversing an <code>aria-labelledby</code> or <code>aria-describedby</code> relation and the referenced node is hidden.</p>

Owner

Author

This is a new comment where I hope to clarify further how UAs should behave when traversing a hidden aria-labelledby/describedby, because the actual logic is spread between 2A and 2B.

It's also true in the case.

Another way of saying it is that the user agent MUST include all nodes in the subtree when the root of the relation was hidden. Correct? Maybe this is even clearer?

It sounds clearer, my wording somehow leaves readers to wonder "what about non-hidden nodes" when there is actually no question: all are hidden and all are included.

This was hopefully made clearer in 688456b.

index.html

Outdated

<li id="step2A">If the <code>current node</code> is <a class="termref">hidden</a> <strong>and is</strong>:

<ul>

<li><strong>Not</strong> part of an <code>aria-labelledby</code> or <code>aria-describedby</code> traversal, where the node directy referenced by that relation was hidden.</li>

<li><strong>Nor</strong> directly referenced by a native host language text alternative <a class="termref">element</a> (e.g. <code>label</code> in HTML) or <a class="termref">attribute</a>.</li>

Owner

Author

This remains as it was, I have been "skipping" this piece of text but when examinating it closely I realized that I really didn't understand it. After some internal discussion, I'm opening a new issue about it: w3c#148

I think we need to word this similar to the first bullet, e.g.
Not part of a native host language text traversal (e.g. label in HTML), where the root of that traversal was hidden.

Reworked this in 94eeb38.

@@ -0,0 +1,2 @@

<p>Indicates that the <a href="#dfn-element" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-element-4">element</a> is not visible, <a href="#dfn-perceivable" class="internalDFN" data-link-type="dfn" id="ref-for-dfn-perceivable-3">perceivable</a>, or interactive to <em>any</em> user. An element is considered <em>hidden</em> if it or any one of its ancestor elements is not rendered or is explicitly hidden.</p>

The first paragraph is wrong, because aria-hidden content is often perceivable visually, when it's not also styled to be visible.
Another problem is that when an element is placed behind something to hide it, or offscreen to hide it, it's arguably still explicitly hidden.
Perhaps there is a benefit from having a table of hiding methods, and for each, describe why it matches the definition of hidden, and if not, what the reason is.

  • CSS display:none, visibility:hidden, visibility: collapse, content-visibility:hidden. Yes, explicitly hidden and not perceivable.
  • CSS opacity: 0 or filter:opacity(0%), or similar SVG mechanisms: No (give reason)
  • aria-hidden: Yes, explicitly hidden
  • Hidden off screen or behind another object: No (give reason)

For me, having this list will help us make sure our definition matches, and is a pragmatic way to make sure implementers and authors have something easy enough to understand, and will be in alignment on the meaning. The abstract definition is just going to be too easy to misunderstand, no matter how careful we are.

Update in b2cfbb8: added these guidelines as a "comment" in the accname spec.

index.html

Outdated

<li id="step2A">If the <code>current node</code> is <a class="termref">hidden</a> <strong>and is</strong>:

<ul>

<li><strong>Not</strong> part of an <code>aria-labelledby</code> or <code>aria-describedby</code> traversal, where the node directy referenced by that relation was hidden.</li>

<li><strong>Nor</strong> directly referenced by a native host language text alternative <a class="termref">element</a> (e.g. <code>label</code> in HTML) or <a class="termref">attribute</a>.</li>

I think we need to word this similar to the first bullet, e.g.
Not part of a native host language text traversal (e.g. label in HTML), where the root of that traversal was hidden.

index.html

Outdated

@@ -272,6 +293,9 @@ <h4>Computation steps</h4>

</ol>

</li>

</ul>

<div><details>

<summary>Comment:</summary>

<p>The result of <a href="#step2B.ii.b">step 2B.ii.b<a> in combination with <a href="#step2A">step 2A<a> means that <a class="termref">user agents</a> MUST include any hidden nodes as part of the <a class="termref">accessible name</a> or <a class="termref">accessible description</a> when traversing an <code>aria-labelledby</code> or <code>aria-describedby</code> relation and the referenced node is hidden.</p>

It's also true in the case.

Another way of saying it is that the user agent MUST include all nodes in the subtree when the root of the relation was hidden. Correct? Maybe this is even clearer?

Owner

Author

To submit this, I think we could include a summary of what user agents will need to change to comply with this text update:

  • Firefox already compliant
  • Chrome would need to change the behavior for aria-hidden. Example: 
    <style>.hidden {display:none;}</style>
<input id="el1" role="button" aria-labelledby="el2" />
<span id="el2" class="hidden">
  <span id="el3" aria-hidden="true">hello</span>
</span>
    Name for the input should be "hello", currently empty in Chrome.
  • WebKit would need to unify behavior between different types of hidden, because it currently produces different names when using display:none and visibility:hidden. Example: 
    <style>.hidden {visibility:hidden;}</style>
<input id="el1" role="button" aria-labelledby="el2" />
<span id="el2" class="hidden">
  <span id="el3" class="hidden">hello</span>
</span>
    Name for the input should be "hello", currently empty in WebKit. It would be "hello" if display:none was used instead.

To submit this, I think we could include a summary of what user agents will need to change to comply with this text update:

  • Firefox already compliant

Firefox actually has some pretty hacky code around this with special cases, last time I checked. I think James Teh will tell us there is much work to be done.

Owner

Author

Moved here: w3c#150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Assignees

No one assigned

Labels
None yet
Projects

None yet

Milestone

No milestone

2 participants

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK