-
Notifications
You must be signed in to change notification settings - Fork 125
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
ARIA should clarify distinction between “contents exposed as descendant text nodes” vs “name from contents” (Was: listitem
should include name from Contents
or name prohibited
)
#2160
Comments
i talked with @rahimabdi briefly this morning about this issue, as it was noticed that HTML AAM also doesn't identify how listitems (or lists for that matter) can be named. But, per my issue about whether roles like listitem should even allow name from author, i similarly wonder why a listitem wouldn't instead just be marked as name prohibited, like paragraphs. actual author naming of listitems has very poor results, fueling my confusing as to why this is treated any differently than paragraphs. i'll save other comments on this for when we talk about it in the meeting. |
Either of those resolutions (prohibited or author w/contents) would work for me, with a preference for whichever changes the implementations less. Since the end user result will more or less be the same. |
Discuss with: w3c/html-aam#543 |
nameFrom: Contents
, shouldn't it?name from contents
(Was: listitem
should include name from Contents
or name prohibited
)
Co-opted this errata issue into the larger conceptual issue since it's clear this is bigger than just listitem. Since some Interop 2024 tests are affected, we should prioritize addressing this one. |
name from contents
(Was: listitem
should include name from Contents
or name prohibited
)listitem
should include name from Contents
or name prohibited
)
Discussed in: https://www.w3.org/2024/05/09-aria-minutes.html#t06 |
WG concluded to add "name prohibited" for listitem to match the pattern for paragraph... core spec and other AAMs can do the same for other roles/elements which are similar to these contexts. |
Minutes from today's meeting: https://www.w3.org/2024/06/13-aria-minutes.html#t09 |
Discussed briefly last week: https://www.w3.org/2024/06/20-aria-minutes#t07 |
ARIA should clarify distinction between “contents exposed as descendant text nodes” vs “name from contents”
This conversation started while @twilco was fixing an implementation bug, and noticed the
listitem
role is limited to name from author (not author/contents), which seems like an oversight in the spec, or there's another ambiguity about SRs using the relevant text from contents in other name-like ways.Link to the version of the specification or documentation you were looking at.
https://w3c.github.io/aria/#listitem
Does the issue exist in the editors draft?
Yes.
Further Discussion
After continued discussion last week, neither
nameFrom: contents
orname prohibited
makes complete sense. Web engines typically leave certain types of elements without names, and let the assistive technologies promote the contents as necessary... Name:prohibited might not make sense on all these types of elements, because there may be a scenario where the web author wants to provide a different name, and "name prohibited" would negate the current "name from author" allowance.In other words, the contents of a list item, paragraph, and several other types of elements are not the name/label itself, but just the content to be spoken/brailled/etc when AT lands on this type of element.
So there potentially could be an explanation in the spec of how several concepts work together:
p
paragraphs have name prohibited, so SRs step into them and read the contents alwaysli
list items currently have name optional from author only, so SRs step into them, but what is intended happens when the author "names" the list item with aria-label, and as name is optional, should the name of this li<ul><li>something</li></ul>
be"something"
or""
(nothing)?Testing Impact
This calls into question a few of the assumptions we made in the tests for the Interop 2024 Accessibility Focus Area. There's at least one erroneous set (below) that will be removed, but there may be more.
The text was updated successfully, but these errors were encountered: