-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Should the UA stylesheet render li elements with markers if the li is not within a list? #10222
Comments
Some context (direct comment link) as to where this issue came from: IOW, is it still a list item? Despite the unexpected (invalid?) context, if it renders the bullet, sighted users will probably perceive this as a list item, so the accessibility runtime should probably convey that to the screen reader or other assistive technology, too. Another variant of the OP that contains the original list context, but includes a generic tweener div: <ul>
<div>
<li>one</li>
</div>
<li>two</li>
<li>three</li>
</ul> |
I am not speaking for any particular implementation team, but I suspect that implementations will not want to deal with the compat fallout of changing UA styles here. Additionally, I don't think we should change HTML's conformance criteria around So the most practical route here seems to me to be changing the AT mapping to match the visual mapping, so that invalid list items are displayed to AT users the same way they are to sighted users. |
thanks for the thoughts, @domenic. i realized when raising this issue that compat would likely be the response to not change the styling. but, figured since it would be changing the styles for invalid use cases, maybe that wouldn't be as problematic.
absolutely agree. i wasn't proposing otherwise. apologies if that wasn't clear.
We can definitely bring this back to the ARIA wg to get consensus on what the mappings should end up being across browsers. i think there's more to discuss concerning what is visually presented and if that's necessarily how it should be mapped or not. but that can happen outside of this issue. thanks |
For the sake of webcompat, shouldn’t the HTML or CSS spec document what is already happening, and therefore define rules for the WPT rendering tests, and subsequently accessibility WPT tests too? I’m not convinced it’s the best approach to leave it to accessibility engineering to figure out what to do about this mainstream rendering ambiguity. If the browsers are all doing the same thing, it should be reasonable to document the behavior. If the browsers are doing different things, we have a compatibility problem the HTML or CSS spec should address, even in the case of an author error. |
Do we have any data how big of a problem this is in practice? |
From talking to Anne offline, the spec-defined UA stylesheet rules (that render the bullets on orphaned list items) may sufficiently address what I called out as an ambiguity. If others agree, then I concur this could be addressed as a mapping issue in HTML-AAM. |
I mean, that's the topic of this issue, right? We should discuss if implementers are willing to change the UA stylesheet here, I think. Above I guessed they wouldn't be, but we haven't gotten any clear word yet from them!
They do. The HTML spec documents that all |
I'm pretty sure that stray Here's a query in httparchive to figure out which tags precede https://docs.google.com/spreadsheets/d/1ea2vV0e8hKaaP-6zelZ_RS98LLq139MVp16b5DB8Jt0/edit?usp=sharing Summary: the table below shows how many pages use
Example: http://lucabenetti.altervista.org/ |
The How to represent the above pages in a useful manner to ATs I'm not entirely sure. In any case, I think the data suggests that we shouldn't change the UA stylesheet. Closing. |
What is the issue with the HTML Standard?
If this belongs over in the CSS WG, I can close and reopen over there.
This topic came up in the ARIA wg yesterday as to how browsers should expose / visually render an invalid use of a
li
element, outside when not a child of a list element container (ul, ol, menu).The spec states that (if a li is not used within a list element container)
The issue here is that while it's clear the spec is saying the list item has no relation to other list items anymore - should the browser still even consider this a single item list? Or should the browser instead not treat this misuse as a single item list and also not style it as such.
Consider the following:
Visually, due to the default UA style that will still look like a single list. And if it visually looks correct, it's less likely that an author will think to make sure it's properly exposed to people using assistive technology, which is where there are browser discrepancies now.
Per the above, chrome/edge and safari do not treat that as a list, but do expose individual listitems. If someone using a screen reader, for example, tried to navigate to what visually appears as a "list" using screen reader commands to jump to lists, they would not be able to. They would be able to navigate by list items, which then creates an inconsistent mental model of what's presented on the page (e.g., there is no list, but there are list items?). Firefox doesn't expose the above as a list, or as individual list items (this matches what is defined in HTML AAM).
Request for consideration
To help mitigate errant markup, should the
disiplay: list-item
not be defined on list items universally, but rather be applied to the li elements only if they are descendants of a parent list element container? (ul, ol, menu, dir)Or, if changing the
display
might have larger consequences, should they not havelist-style: none
if they list items are not a descendant of a list?Alternatively, if people do not think that removing the listitem semantics is the correct route, then should browsers instead be instructed to attempt to 'fix' such lists? In which case, the text I quoted from the list item definition might then need to change.
The text was updated successfully, but these errors were encountered: