Discussion: Should AccName split name/label from contents (descendent text node contents)?

[cookiecrook]

@scottaohara has previously posed the idea that including descendent text content as the AccName value (e.g. for a <p> tag) complicates the discussion and sometimes the implementation. For example, there isn't a meaningful distinction in AccName between links and buttons, despite buttons being leaf nodes (childrenPresentational: true). These are further complicated by labeled group nodes like headings that should use nameFrom: contents, but that may contain several individual, even interactive child nodes.

I agree we should consider making this type of change in AccName or elsewhere, and that participants of that discussion should include major browser implementors, and multiple AT vendors. Is this a TPAC-worthy discussion topic?

More from a related WPT PR on how CSS generated content pseudo-elements fit into that equation:

Thank for writing some tests on the ::marker pseudo-element and how its generated content contributes to AccName. I have a few questions, starting with, "Do we think ::marker should be processed the same or differently than how ::before should be processed?"

This comes back to @scottaohara's question in the ARIA meeting this morning. Is this the label, or the content? IIRC, WebKit exposes generated content nodes as additional, separate text nodes which are children of the element node along with the element's contents as a sibling text node. These are later concatenated, if appropriate, by the downstream assistive technology (AT)...

AT use cases differ, so for example, a screen reader user may want to hear the generated content like a bullet before a list. A sighted ZoomText/HoverText user may not want to hear the extra bullet. So we probably need to keep them separate in the platform APIs.

As long as the engines implement AccName contribution in a way that remains separable by downstream AT, I think it's okay to include this in computed label, but if that's the case, this value (when it contains generated content) may end up being an unused implementation detail, so passing WPT results could give us a false sense of security. That may be okay—we could test it downstream later with Acacia perhaps—but maybe this topic is worth discussing at TPAC, especially if @jcsteh or other AT contributors can be in attendance.

Originally posted by @cookiecrook in https://github.com/web-platform-tests/wpt/pull/54222#pullrequestreview-3186943430