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

jaragunde · 2022-01-31T16:49:47Z

…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.

…or -describedby.

jaragunde · 2022-01-31T17:29:16Z

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

index.html

jaragunde · 2022-02-01T10:34:50Z

index.html

+                    <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>


These examples are new, too.

jaragunde · 2022-02-01T10:35:37Z

index.html

+                    </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.


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

jaragunde · 2022-02-01T10:39:28Z

index.html

-              </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>:


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

aleventhal · 2022-02-01T15:01:27Z

…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:

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.
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.
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

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

index.html

jaragunde · 2022-02-03T08:59:36Z

We should mention there are a few possibilities:

Always remove aria-hidden content from any name calculation...

Use the same rules for aria-hidden as other types of hidden...

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.

This reverts commit 83229c0.

jaragunde · 2022-02-08T18:28:55Z

hidden-definition.html

@@ -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>


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.

jaragunde · 2022-02-08T18:31:54Z

index.html

-            <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>


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

jaragunde · 2022-02-08T18:33:09Z

index.html

@@ -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>


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.

jaragunde · 2022-02-08T18:48:57Z

index.html

+            <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>


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.

aleventhal · 2022-02-10T15:25:03Z

hidden-definition.html

@@ -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.

aleventhal · 2022-02-10T15:28:31Z

index.html

+            <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.

aleventhal · 2022-02-10T15:31:01Z

index.html

@@ -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?

Revert proposed changes to the "hidden" definition in wai-aria and add instead a section clarifying the specific hidden methods.

jaragunde · 2022-03-11T12:12:00Z

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.

aleventhal · 2022-03-14T15:07:53Z

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.

jaragunde · 2022-03-15T09:37:55Z

Moved here: w3c#150

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

54a3124

…or -describedby.

jaragunde added 2 commits January 31, 2022 18:36

Editorial changes.

6834cf4

Add clause about aria-hidden.

83229c0

jaragunde commented Feb 1, 2022

View reviewed changes

index.html Outdated Show resolved Hide resolved

jaragunde commented Feb 1, 2022

View reviewed changes

aleventhal reviewed Feb 1, 2022

View reviewed changes

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved Hide resolved

index.html Outdated Show resolved 10000 Hide resolved

jaragunde added 4 commits February 3, 2022 12:02

Revert "Add clause about aria-hidden."

da02ba0

This reverts commit 83229c0.

Simplify cases in step 2A and add clarification.

3a83955

Add original hidden definition from wai-aria.

059c7a2

Add clarification to hidden definition.

16bf253

jaragunde commented Feb 8, 2022

View reviewed changes

Tune the examples to make them more understandable.

6ab05d0

aleventhal reviewed Feb 10, 2022

View reviewed changes

jaragunde added 4 commits March 11, 2022 11:49

Add explicit guidelines for "hidden".

b2cfbb8

Revert proposed changes to the "hidden" definition in wai-aria and add instead a section clarifying the specific hidden methods.

Rework point about native host language text alternative

94eeb38

Rework comment about combined behavior of 2B.ii.b and 2A

688456b

Markup fix.

f27737d

jaragunde closed this Mar 15, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

		@@ -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>

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

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

Conversation

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment