Add accname tests for ::marker pseudo content

[adampage]

Related: Issue w3c/aria#2596 → Accname PR w3c/aria#2606

[cookiecrook]

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 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 contents as its own text node, and are later concatenated by the downstream assistive technology (AT)...

AT use cases differ, so for example, a screen reader user may want to hear the generated content. A ZoomText/HoverText user may not want to hear the extra. So we 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.

[cookiecrook]

Approving either way since this matches the spec and is testable today. I pulled out my previous AccName discussion comment into a new linked ARIA issue.