ISSUE-748: Step 2F: The algorithm does not seem to handle nesting like it thinks it does
Step 2F: The algorithm does not seem to handle nesting like it thinks it does
- State:
- CLOSED
- Product:
- ARIA 1.1 Name Computation
- Raised by:
- Cynthia Shelly
- Opened on:
- 2015-11-14
- Description:
- The algorithm does not seem to handle nesting like it thinks it does, at least if it is using the information in the html-aam document (linked above). Using their own example:
<label><input>Make this the <em>top</em>most element</label>
They say the name should come out as “Make this the topmost element”. However, following the algorithm, we’ll get to step 2.F, and start walking the children of the label. <em> is a child of the label, not the text node, so we’ll recurse into the algorithm for this node. It isn’t special, so it’ll hit step 2.D. which says use the native markup text alternative. Using the html-aam document, <em> elements are specifically covered in 5.11 and since there is no aria nor title, the element does not have a name. It does not say to use the subtree.
Perhaps “name from: contents” is supposed to cover practically all nodes except in very specific circumstances, in which case we’d be fine as we’d recurse into the subtree and handle the text node properly. In HTML, I believe any node can have a subtree, even if it is not rendered, meaning anything could get its name from its contents?
- Related Actions Items:
- No related actions
- Related emails:
- No related emails
Related notes:
Off the top of my head, the HTML elements <br>, <img>, and <input> are content-less, and there may likely others. In SGML-speak, they do not have a content model. As such, one cannot compute a name-from:contents with these elements.
I am looking at this and the issue not being addressed is native host language elements that support descendant elements, like <em>.
I would recommend modifying this from:
Otherwise, if the current node's role allows name from content, or if the current node contains content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML):
to:
Otherwise, if the current node's role allows name from content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML):
I am looking at this and the issue not being addressed is native host language elements that support descendant elements, like <em>.
I would recommend modifying this from:
Otherwise, if the current node's role allows name from content, or if the current node contains content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML):
to:
Otherwise, if the current node's role allows name from content, or if the current node has no defined role and contains content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML):
Created pull request for changes: https://github.com/w3c/aria/pull/611
Richard Schwerdtfeger, 21 Jul 2017, 12:23:33added a new step to address embedded <em>s. It was tried and it works. this was done in pull request 611 for issue748. I merged the branch and closed the issue.
Richard Schwerdtfeger, 20 Aug 2017, 13:03:38Display change log
