listitem should not be exposed as generic if it is rendered as a list item visually

[tranjocelyn]

In html-aam/roles-generic.html, there is a listitem that is expected to be exposed as a generic role:

<li data-testname="el-li-orphaned" class="ex-generic">x</li>

However, when roles-generic.html is loaded in the browser, that listitem is rendered as a listitem (there is a bullet next to the x). We should render the same thing to screen users as well, i.e., we should expose the list item as a list item, not a generic.

[aleventhal]

+1. If the a11y tree is stricter than the overall rendering engine, then AT users will get a different experience from everyone else.

[aleventhal]

@scottaohara @jcsteh @cookiecrook looking for opinions.

[scottaohara]

w3c/html-aam#540

if the li is used incorrectly (e.g., not within a ul, ol or menu) then it should not be a listitem. This would be similar to if someone had done <p>&bullet; whatever....</p>

so

<p>&bullet; not a list item....</p>
<li> also not a list item, because not within a list, and visually similar to the previous paragraph which is _not a list item_</li>
<p>...

but per some clarifications that were added to the HTML AAM PR I added, if the markup structure is as follows:

<ul>
  <div> <!-- invalid HTML but doesn't cause the parser to restructure the DOM -->
     <li> _this_ should still be a list item since it's accessibility parent is a list (ul element) </li>
      ...
  </div>
</ul>

[aleventhal]

if the li is used incorrectly (e.g., not within a ul, ol or menu) then it should not be a listitem.

I'm not sure I 100% agree because this could break existing content.

I don't think it's a good idea that if an author specified an <li> that we change how we've been exposing it for over a decade. I don't want to deal with all the regressions. It will be busy work with no real user benefit. IMO We should let this go instead of being semantic stalinists :)

[scottaohara]

would chrome be willing to go the opposite way then? fixing broken lists per the invalid markup and essentially wrapping orphaned list items into a "list" container in the a11y tree? (that could get quite messy per some of the errant markup i've seen... i won't bore you with those details for now)

Either way, the intent of the change to the role was to fix invalid use of li elements and the inconsistent experience that gave users. If used incorrectly, people can "see" a list of items, but they aren't semantically conveyed as such. there is no x of y information exposed for the AT that expose that sort of thing. Someone can't use the "list" hotkey to navigate to the start of such items.

So, the following will "look" like a list - but no browser will expose it as a list.

<li>...</li>
<li>...</li>
<li>...</li>

Which then makes it unexpected when someone does try to navigate by listitems, expecting to reach a known proper-list in a page, but instead navigates to an item or items which weren't exposed as lists. Especially for instances where people haven't used errant listitems so neatly, and they're instead separated by other arbitrary content.

This isn't an attempt to be a semantic stalinist - i see it as the opposite of that since the intent is to remove the semantics when used incorrectly, rather than say something is a list item but that it won't be treated the same as properly constructed list items within a list container.

I recently spoke with @cookiecrook about this and on macOS/iOS, since listitems aren't directly navigable / there is no 'listitem' role announcement, there isn't any real difference to a user (for any browser on macos/ios) between <p>&bullet ...</p> vs an orphan <li>...</li>.

On Windows, Firefox already exposes invalid li elements as generic. I'd be interested to know if there has been any user complaints about this. If so, then there's a data point that this change wasn't helpful.

[aleventhal]

@jcsteh Since Firefox is already doing this, I'm fine with it if it hasn't caused issues with existing content, or you see it as an improvement. I've just had a lot of times where well-meaning changes like this cause a regression in Slack, and we don't find out until it's in a stable version.

[jcsteh]

Honestly, I don't personally agree with the orphaned roles stuff at all. I think they should all be authoring requirements, not enforced by the UA. However, the spec and tests disagree - see web-platform-tests/interop-accessibility#109 - and we didn't feel it was worth pushing for this to be changed, assuming it had been specified this way for good reason. So, we implemented according to the spec.

FWIW, I haven't seen any regressions in the wild since we implemented this, either personally or bugs filed by others, but that doesn't mean there aren't any.

[jcsteh]

CC @nmlapre.

[aleventhal]

@james Teh ***@***.***> since Firefox already implemented and it hasn't caused any major issues, I think we'll implement and not push back further. Thanks for the info.

…

On Mon, Apr 15, 2024 at 6:28 PM James Teh ***@***.***> wrote: CC @nmlapre <https://github.com/nmlapre>. — Reply to this email directly, view it on GitHub <#45715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZXH3EA5MZ3XMU7H7KLY5RIBDAVCNFSM6AAAAABGHYGYLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXHEYTMMJTG4> . You are receiving this because you are subscribed to this thread.Message ID: <web-platform-tests/wpt/issues/45715/2057916137 <(205)%20791-6137>@ github.com>

[jcsteh]

@nmlapre did remind me that this only landed in Nightly 6 days ago, which might be too short a time to say "there haven't been any regressions" with a great deal of certainty. I'll keep watching and update here if I spot any breakage in the wild, either personally or thanks to bug reports.

[scottaohara]

@jcsteh i'm surprised to hear you say that, because i'm using Firefox version 120 right now and looking at an orphaned li element in the a11y tree, it is reported as generic. jaws and nvda treat it as such. so i was under the impression this had been around for at least 5 versions, since i see the latest public release is firefox 125?

[jcsteh]

Ah, interesting. It seems that's true for <li>, but not, for example, <div role="listitem">. Markup elements are handled somewhat differently to ARIA roles and we had a specific code path to handle the orphaned <li> case. That was implemented 12 years ago. Sheesh!

[nmlapre]

Minor addition to Jamie's comment: The 12-year-old code says that Gecko does this specific list item behavior "to avoid text jamming". I landed the change for role="listitem" and friends on the 10th.

[scottaohara]

thank you both for clarifying.

as this topic was only about the li element, i wasn't even thinking to check role=listitem and why i was so confused with what was being said vs what i had been seeing. I even went back to the files i created for testing when I made the HTML AAM PR, and i had written down my results, stating "firefox already treats li elements as generic when incorrectly used outside of a list"

[jcsteh]

That's fair and I apologise for the confusion. Honestly, I had completely neglected to realise that this 12 year old code even existed. We needed to make additional changes (the ones landed on the 10th) to pass the other orphaned role WPT tests and I had incorrectly assumed those covered <li> as well.

[tranjocelyn]

thanks for the info everyone, this was very helpful.