-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Name from content must not always use child nodes (Step 2 F iii) #153
Comments
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: |
Actually, Chrome divides things into a few cases. We should look at codifying it. General categories, based on role:
|
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. |
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
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. |
And the next question would be whether this rule is good? With this link (link with a timer as a child):
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). |
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.
|
@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. |
Yes, I understand that. I just wonder if |
"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. |
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.
The text was updated successfully, but these errors were encountered: