When is hidden content taken into calculation of name and description?

[JAWS-test]

Unfortunately for me (as well as for the browser manufacturers and developers of assistive technology: FreedomScientific/standards-support#251) the procedure for determining labeling and description is too complex (https://w3c.github.io/accname/#terminology) and I would therefore like to know how to proceed with hidden content according to the specification.

For which label types is hidden content output valid?

• aria-labelledby
• aria-describedby
• label for
• enclosing label
• legend in fieldset
• figcaption in figure
• caption in table
• determining accessible name and description for elements within a Live Region
• ...

When does it apply?

• Label or description itself is hidden
• Descendant elements (of label or description) are hidden
• Ancestor elements (of label or description) are hidden

If I'm not the only one who doesn't see this directly from the specification, I'd ask you to be more precise in the specification and possibly give some examples of when hidden content is output and when not.

See also: w3c/aria-practices#1136

[JAWS-test]

I understood before testing and before the discussion with @mcking65 (FreedomScientific/standards-support#251)

According to the specification, hidden text should be output as label when using label for or aria-labelledby or aria-describedby. However, this only applies if the label itself or an ancestor element is hidden

Since the test and the discussion, I no longer know exactly what the specification actually wants to say. In addition, the specification leaves open the labeling method for which the rule applies (see above: List of labeling methods).

[accdc]

Hi,
This is something that will be better explained in future edits of the AccName spec, and there are some misconceptions as you documented above.

The only attributes that are permitted to reference hidden elements are aria-labelledby and aria-describedby. Also, this is only true if the referenced element is explicitly hidden using CSS display:none or visibility:hidden, or the HTML5 hidden attribute.

However, if the ancestor element of the referenced element is hidden instead, making the referenced element implicitly hidden, then it will not be exposed. This decision goes back to prior discussions we had regarding this subject in the ARIA WG, where we agreed this would be the most intuitive course to document going forward.

In contrast, if a referenced element includes hidden children, whether by CSS or the hidden attribute or the aria-hidden attribute, then those hidden elements will not be included in the computation.

You can try out these various combinations on the live test page at
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

Simply add id="test" to the markup that you want to compute the accessible name for by pasting the code in the edit field at the end of the page, then activate the Paste & Test button, which will load the markup and compute the name for the referenced element. Also, if your markup includes focusable elements, the accessible name and description property values will automatically be computed as you tab between each focusable element after you render it within the page.

[JAWS-test]

Hi @accdc
Thank you so much for your explanation. It is very clear and understandable. Unfortunately this clear language is missing in the various specifications (Accname, ARIA) and other documents (like ARIA Practice). Also this is not implemented by assistive technology at the moment. Therefore I would like to suggest to add this in the specification so that it is clear for everyone.

[JAWS-test]

@accdc

I tried https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html and discovered a case that I find strange:

<input aria-labelledby=1 id=test>
<span hidden id=1>1 
     <span aria-hidden=true>2</span>
</span>

I would have expected accName to be "1," but it'd give out "1 2." The "2" should not belong to the accName because of the aria-hidden=true at the inner span. It also works correctly if the outer span element is not hidden.

[JAWS-test]

The result of

<input aria-labelledby=1 id=test>
<span aria-hidden=true id=1>1</span>

I also find surprising: "1" because you wrote indirectly that it does not apply to aria-hidden

[mcking65]

@accdc commented:

However, if the ancestor element of the referenced element is hidden instead, making the referenced element implicitly hidden, then it will not be exposed. This decision goes back to prior discussions we had regarding this subject in the ARIA WG, where we agreed this would be the most intuitive course to document going forward.

Bryan, If I understand, you are saying that in the following code, the first input has a name and the second one does not.

<div id="1" hidden>My Label</div><input type="text" aria-labelledby="1">
<div hidden><div id="2">My Label</div></div><input type="text" aria-labelledby="2">

Can you point to where and when the WG made a decision to do this? I don't recall when we may have gone in this direction.

I don't understand the purpose. To me, it seems like a very odd querk to throw into the algorithm, and it makes it even more mysterious . It feels counter to what would be intuitively expected. I don't see language in the definition of aria-labelledby or aria-describedby to support it. For that matter, there is no language in the spec that even suggests hidden content may be referenced, which seems like a major oversight.

[jongund]

Based on the discussion in the 5 May 2020 teleconference a summary of this issue:

In general the aria-labelledby algorithm for computing accessible name ignores whether something is hidden or visible. Hidden currently only makes a difference when concatenating descendant nodes of a referenced visible node and a descendant node is hidden. The hidden node and its descendants are currently not included in the accessible name. There is probably a special case for when something is hidden using the CSS visibility property and a descendant of the hidden node is switched to being visible. In this case the visible content would be included in the accessible name. The following is a table of different conditions and the affects of a hidden descendant node.

Effect on Accessible Name Calculation for hidden descendants of a visible node referenced in an aria-labelledby

Descendant Hiding Technique	accname Calculation	Special Cases
HTML hidden attribute	hidden descendant node and all of its descendants are not included	none
CSS display: none	The hidden descendant node and all of its descendants are not included	none
CSS visibility: hidden	The hidden descendant node and all of its descendants are not included	Any descendant nodes of the hidden node that are made visible through visibility: visible are included in the accessible name calculation
ARIA aria-hidden: true	The descendant node not included in the accessibility tree and all of its descendants are not included	Depends on resolution of Issue 1256

[accdc]

Hi,
As we discussed today:
https://www.w3.org/2020/05/07-aria-minutes.html#item04

I've updated the AccName Prototype to reflect the WG decision to ignore both implicit and explicitly hidden states on elements directly referenced by aria-labelledby and aria-describedby, regardless if the referenced element is hidden or if one of its parent elements is hidden instead.

It also takes into account if a child element is explicitly hidden as well, such as when aria-hidden="true" is used, which should be ignored as documented in the AccName algorithm for recursive processing.

Example:

<div hidden>
<i id="desc">This is a description.
<b aria-hidden="true">This should stay hidden.</b></i>
</div>
<input title="Field Name" id="test" aria-describedby="desc" />

Result:
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

accName: "Field Name"
accDesc: "This is a description."
(Running AccName Computation Prototype version: 2.49)

This may need to be clarified within the spec text.