Name from content must not always use child nodes (Step 2 F iii)

[JAWS-test]

There are nested elements (e.g. treeitem) where the child elements are in the parent element. AccName of these elements should not be the labels of all child elements. Therefore, step 2 F iii should be excluded for these elements.

The browsers do it correctly, but the specification does not say so.

[accdc]

Hi, I agree we should make this more clear. There is a general process defined behind the scenes that we have worked out that deals with this, which is that roles that do not support name from content do not have their names computed during the recursive algorithm when computing the name of a parent node.

This is why the nested treeitem example works in browsers, because nested treeitems have to be contained within an element with role=group. Since role=group does not support name from content, it is not included when recursively computing the name of the parent treeitem node.

This works all over the place too. For example when an element with role=gridcell includes a nested role=radiogroup container that includes multiple radios, and so on. The role=radiogroup container is not included.

Additionally, this also applies to native elements as well that have implicit ARIA roles, such as when a heading element includes a nested select element, or even a role=listbox container filled with many options. Since none of these controls include name from content support, none of their contents are included in the name computation for the parent heading element.

There are some grey areas in this which we had to hammer out, which makes it even trickier to define formally, though it does need to be done somehow. You can see the prior discussion about this at: https://lists.w3.org/Archives/Public/public-aria/2017Jun/0057.html Which has evolved a bit since then with some changes, but it may help provide some background.

[aleventhal]

Actually, Chrome divides things into a few cases. We should look at codifying it. See AXObject::SupportsNameFromContents() here, I think it's reasonably easy to understand even if you don't know C++: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_object.cc;l=5855?q=supportsnamefromcontents&ss=chromium

General categories, based on role:

1. Always compute name from contents or contribute recursively to an ancestor name from contents
2. Never compute name from contents or contribute recursively to an ancestor name from contents
3. Conditionally compute name from contents if needed to for recursive contribution to ancestor name from contents, or if focusable (but not in a contentedtiable)

[accdc]

Thanks, that would be great. I would need your help or someone familiar with the code to write a draft spec text proposal that makes sense however from an implementer perspective. Would this be doable?

There are some grey areas that we need to somehow track as well, where it is valid markup to do but may cause issues in the computation, such as if a list element or a table is included in a heading and how and where not to suppress recursion even if the element does not support name from content.

[JAWS-test]

@accdc

which is that roles that do not support name from content do not have their names computed during the recursive algorithm when computing the name of a parent node

This does not seem to be true, since all roles that are not allowed to be labelled contribute to the labelling of a parent element with their content in the case of name from content.

Example: link with generic child = content of generic is part of the link label

<div tabindex=0 role=link>link <span role=generic>generic</span></div>  

So the rule seems to be: name from content only works in the recursion to child elements if these either allow name from content themselves or must not be labelled at all. This rule should be in AccName, which is currently not the case.

[JAWS-test]

And the next question would be whether this rule is good?

With this link (link with a timer as a child):

<a href=test>Reload after <span role=timer>3</span> minutes</a> 

I would expect the number "3" to be part of the link label. Unfortunately it is not (Firefox ignores the rule here and includes the 3, Chrome adheres to the rule).

[JAWS-test]

Quite apart from the fact that the rule does not always seem to apply. If a list is in a link, the content of the list is used as the link label, although neither role=list nor role=listitem allow name form content. Chrome, Firefox and AccName Prototype Test break the rule here.

<a href=test><ul><li>1<li>2</ul></a>    

[accdc]

@JAWS-test That's what I was trying to point out, that this is a lot more complicated behind the scenes because some things make sense to pass through at certain times and others do not. Generic for instance always needs to be passed through. I'll see if I can get this topic added to the agenda soon so we can figure out how to document these things better.

[JAWS-test]

that this is a lot more complicated behind the scenes because some things make sense to pass through at certain times and others do not

Yes, I understand that.

I just wonder if a) this should be correctly reflected in the AccName specification. b) if the method "behind the scenes" should be adjusted in a meaningful way, at least where it leads to weird results and browsers themselves disagree on what is correct (see my examples)

[accdc]

"a) this should be correctly reflected in the AccName specification."

I agree it probably should. Hopefully we can work out a way of doing this soon. This really is an important part of the computation that needs to be documented.