Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AccName algo probably needs an update for ::marker #203

Open
cookiecrook opened this issue Oct 5, 2023 · 8 comments
Open

AccName algo probably needs an update for ::marker #203

cookiecrook opened this issue Oct 5, 2023 · 8 comments
Assignees

Comments

@cookiecrook
Copy link
Contributor

cookiecrook commented Oct 5, 2023

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.

@cookiecrook
Copy link
Contributor Author

cookiecrook commented Oct 5, 2023

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

@cookiecrook
Copy link
Contributor Author

Cc @fantasai to keep me honest

@cookiecrook
Copy link
Contributor Author

@scottaohara
Copy link
Member

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
Copy link
Contributor Author

cookiecrook commented Oct 6, 2023

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
Copy link
Member

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
Copy link

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.

@Loirooriol
Copy link

See #76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants