[html-aam PR 540] Clarify li element role mapping

[pkra]

Moved from w3c/html-aam#540

edit:
closes #2173
approving reviewers from migrated HTML AAM PR: @smhigley, @cookiecrook, @spectranaut

edit again:
pointing back to the original HTML AAM PR that this is one is clarifying - w3c/html-aam#476

• "author MUST" tests: n/a
• "user agent MUST" tests: LI element role tests web-platform-tests/wpt#49643
• Browser implementations (link to issue or commit):
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations? no
• Related APG Issue/PR: n/a
• MDN Issue/PR: n/a

[scottaohara]

my manual test results - https://codepen.io/scottohara/pen/LEPRRNd
WPT - web-platform-tests/wpt#49643

[cookiecrook]

(Though I have no problem with this minor editorial change) I recall a conversation (perhaps with @twilco, @nmlapre, and @jcsteh) that downgrading the orphaned roles had no user benefit, and had implementation cost, so the related WPT tests were rolled back or moved to tentative. I think that means this line should be removed from the spec, too.

[scottaohara]

@cookiecrook that convo definitely happened regarding the use of explicit aria roles that weren’t children of their required parents, but html’s li element contextual role was separate to that. Firefox has been treating an orphan li element as generic for 12 years now.

If Firefox is willing to undo this and then all browsers consistently expose the li element as a list item, even when not within a required ul, ol, menu or role=list parent - then it can become a screen reader’s decision on how to handle these author errors, or not. Maybe this is even the way Firefox can resolve the failing tests for <ul><div><li>not a list item in firefox</div></ul> and <ul aria-owns=f></ul><li id=f>not a list item in firefox

[jcsteh]

I came across a case yesterday which would break if we removed the rule for orphaned <li> elements. This also led to the realisation that Chrome sometimes does this too.

data:text/html,<ul style="list-style: none;" role="tablist"><li><button role="tab">foo</button></li><li><button role="tab">bar

If the <li> elements got a role of listitem, this would break the posinset/setsize calculation for the tabs. What's interesting here is that in this case, Chrome excludes the <li> element from the tree. Conversely, if you do this:

data:text/html,<li>foo

Chrome exposes listitem. But if you do this:

data:text/html,<ul role="none"><li>foo

Chrome excludes the <li>. So now I don't know what to think. 😕

[cookiecrook]

html’s li element contextual role was separate to that.

Okay, thanks for the reminder that was separated.

[cookiecrook]

Approving with the caveat this would change long-standing implementation support, so we need broad engine stakeholder buy-in.

[spectranaut]

Moving over approval from previous PR.

[spectranaut]

@scottaohara this has three positive reviews (including @smhigley from the old PR), and tests, I think that we should open bugs on browsers for this change?

[scottaohara]

do wpts need to be merged before bugs can be filed? the wpt for this one still needs to be merged. is that a before or after activity? @spectranaut @cookiecrook ??

[spectranaut]

I don't think WPT PRs need to be merged before bugs are filed. Probably the spec PR and the test PR should land at the same time.

iirc if the WPT PRs land first, they should be marked as "tentative" which sounds like a hassle to do every time.