Add "Name from Content" accname step for ::marker pseudo-element

[rahimabdi]

Closes w3c/accname#203

Describe Change Here!

The accname algorithm should account for ::marker CSS-generated content. This PR for provides spec guidance on ensuring ::marker content (that is visible and where the current node supports it) is included in the accname computation.

Test, Documentation and Implementation tracking

Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.

• "author MUST" tests:
• "user agent MUST" tests:
• Browser implementations (link to issue or commit):
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations?
• Related APG Issue/PR:
• MDN Issue/PR:

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	46f65ce
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/679af1d373876d0008b3af0d
😎 Deploy Preview	https://deploy-preview-2419--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[scottaohara]

Not opposed to the current wording, but this is how my mind had to translate what was said. just throwing it out as a suggestion as alternate wording.

Suggested change

	elements [[!CSS2]] can provide textual content for [=element|elements=] that have a content model, in addition to [=element|elements=] that support the <a href="https://www.w3.org/TR/css-pseudo-4/#selectordef-marker"><code>::marker</code> pseudo element if it is visually rendered.
	elements [[!CSS2]] can provide textual content for [=element|elements=] that have a content model. The CSS <a href="https://www.w3.org/TR/css-pseudo-4/#selectordef-marker"><code>::marker</code> pseudo element</a> can also provide textual content for [=element|elements=] that support the pseudo element.

I left out the "if it is visually rendered" bit since that wasn't part of the previous spec text - and it might get confused due to specifically saying "visually rendered" - which is only introduced here in the spec. e.g., opacity: 0; or scale: 0 would be rendered - but not "visually" since they'd be invisible or shrunk to the size of not being visible. does that mean it wouldn' be included then? (my answer would be no - opacity 0 or scale: 0 should not hide content from the a11y tree)

[rahimabdi]

@scottaohara Agreed. My only concern would be for lists, where ::marker is automatically generated depending on list-style-type so I'm curious about the scenario where list-style-type: none visually suppresses the marker (and perhaps list semantics). For ::marker only (and not other CSS properties like opacity, scale), should it be conveyed if it's not visually present?

[scottaohara]

just not sure about "visually rendered" here, per my previous comment. but otherwise think this is fine.

[MelSumner]

I think the visually rendered part is fine, especially since this is related to CSS (which is all about what's visually rendered.

[scottaohara]

I think the visually rendered part is fine, especially since this is related to CSS (which is all about what's visually rendered.

but as i've already mentioned, there are properties in CSS that do not visually render content (in that they are rendered, but not visible), but they are still included in the accName.

one can't even make the argument that "well they still take up space in the layout, so that counts as their visual rendering" because visibility: hidden content also still takes up space in the visual rendering of the layout - but THAT content is similar to display: none and not exposed to the a11y tree by default.

[rahimabdi]

I think the visually rendered part is fine, especially since this is related to CSS (which is all about what's visually rendered.

but as i've already mentioned, there are properties in CSS that do not visually render content (in that they are rendered, but not visible), but they are still included in the accName.

one can't even make the argument that "well they still take up space in the layout, so that counts as their visual rendering" because visibility: hidden content also still takes up space in the visual rendering of the layout - but THAT content is similar to display: none and not exposed to the a11y tree by default.

Thank you @scottaohara @MelSumner. I'm happy to remove the "visually rendered" part. Scott brings up a good point that "visually rendered" isn't existing accname spec language so my only outstanding concern is with treatment of list-style-type: none and if ::marker should participate in accname for that case.

Also, since list-style supports unicode characters, a string value and even images (list-style-image), I'm curious if you think it would beneficial to call these out as well.