AccName algo probably needs an update for ::marker

[cookiecrook]

AccName algo (Name from Content section that covers pseudo elements) probably needs an update for ::marker, which—if I understand correctly—comes before ::before, but can also have another ::before::marker before ::before (but after *::marker), and an ::after::marker after the element contents but before ::after.

• https://www.w3.org/TR/css-lists-3/#marker-properties
• https://www.w3.org/TR/css-pseudo-4/#selectordef-marker

[cookiecrook]

I hope I got all that right, because it was the most fun I've ever had writing a GitHub issue. 🤣

[cookiecrook]

Cc @fantasai to keep me honest

[cookiecrook]

Noticed while working on:

• https://github.com/web-platform-tests/interop-2023-accessibility-testing/issues/36

[scottaohara]

as an FYI - i had opened an issue against firefox concerning the summary element, where "Filled down pointing small triangle" or "Filled right pointing small triangle" was being included in the accessible name of the summary element, and causing a name change event to fire each time the disclosure was toggled.

not sure what the expected end goal was for ::marker in accName, but per the above, if the intent is to include it - i think i'd at least situationally object to that.

[cookiecrook]

I dunno. Maybe the default style sheet should explicitly override the alt value in scenarios where it's undesirable:

details:not([open]) > summary::marker {
  content: "▶";
  content: "▶" / "";
}

So that the <party> element marker can still be accessible, etc.

party::marker {
  content: "🎉"; /* or even `content: "🎉" / "Party!";` */
}

No one wants to attend your disability-segregated parties, @scottaohara! 🤣

[scottaohara]

that's fine, since i've equally not invited anyone to said parties. cleanup is such a chore.

but point very much taken. my reaction stems from all the times I see UAs and authors use this (and ::before/::after) and the information the pseudo conveys which is redundant if not nonsensical to be added to the accName. but maybe that wouldn't be as much of a problem if more than chromium browsers supported setting alternatives for this content?

[rahimabdi]

This will need to take into account list-style-image where the list marker can be image based (i.e., little spaceships in lieu of bullets or numbers).

It's unclear how ATs treat image-based list markers generally since they don't have text alternatives although CSS content alternative text may be a good technique for providing an accname if supported.