Clarifications to allowed roles on li element

[scottaohara]

ARIA in HTML is clarifying the allowed roles on li elements.

No role if the parent list element has an implicit or explicit list role.

Otherwise, any role.
NOTE: See ul, ol, or menu for allowed roles for list elements.

This update disallows any role on an li element so long as it is a child of a ul, ol or menu element is exposed as an implicit or explicit role=list. A role of listitem could produce a warning for unnecessary use of a redundant role.

However, if the parent ul, ol or menu has its implicit list role overwritten, then the li may have Any role so long as that role is an allowed role of its ancestor elements.

For example, the following li may have a role=button specified as the parent list element as a role=none

<ul role=none>
  <li role="button" ...>...</li> <!-- allowed because ul is no longer a 'list' -->
</ul>

However, as the following ul has a role=menu specified, the role=button is not allowed. The only allowed roles for the li would be menuitem, menuitemcheckbox or menuitemradio (or none/presentation so long as within the li there is one of the menteioned menuitem* roles).

<ul role=menu>
  <li role=button>...</button> <!-- not allowed because child of menu -->
</ul>

similar to the following, as while the ul has a role=none, it is a child of a role=tablist, so therefor the li may only have a role that is an expected descendant of a tablist.

<div role=tablist>
  <ul role=none>
    <li role=button>...</li> <!-- not allowed because owned by tablist -->
  </ul>
</div>

Finally, even though the following would be flagged for invalid HTML, the li is again allowed any role as it is exposed as a generic role when not correctly nested within a list element:

<article>
   ...
   <li role=note>...</li> <!-- allowed -->
   ...
</article>

Additional test cases provided here.

[shunguoy]

need more investigation from triage. Is this already done in the current parent-child check?

[tombrunet]

This is about aria_semantics_role for li in that other roles should be allowed if the parent container has a role. It's currently a false positive. The test case of interest is:

<ul role=none>
    <li role=button>...</li> <!-- not allowed because owned by tablist -->
  </ul>

A lot of the other scenarios are picked up by other rules.

[shunguoy]

@scottaohara is this change still pending? I don't see the change in ARIA in HTML recommendation or draft. thanks for the clarification.

[scottaohara]

@shunguoy yes. The hold up for any PR is because the ARIA in HTML spec is following the W3C's living standard model, where we try not to merge changes into the spec until we get at least 2 implementations / commitments for implementation.

The intent here is to try to help conformance checkers not have gaps in their support - e.g., if we merged this without your implmentation, then this checker would have a gap. But, if we wait for implementations, then the rules better reflect the checkers.

If, however, this is not working for you and your team needs this merged into the spec before you will work on it, then we will forgo this method and instead just merge changes into the spec. Though that will mean your team will be more likely to have gaps in what the spec says vs what your tool reports.

[shunguoy]

@scottaohara thanks

[tombrunet]

@scottaohara If the container (ul, ol, etc) has an explicit role like none or presentation, what is the implicit role of the li? Chrome gives it no role. I don't see anything in the ARIA in HTML spec that would indicate that.
See https://codesandbox.io/s/zen-voice-483zl3?file=/index.html

[scottaohara]

@tombrunet that's a bit of a browser heuristic right now. It wouldn't be defined in ARIA in HTML, but rather HTML AAM. I have been working on something to address this 'undocumented' behavior in that spec. But I can call this out more overtly in the current PR as well, if this is something you'd need mentioned before work can be done.

Edit: this PR should make it more clear in the AAM spec, in lieu of the larger update i referenced, and once this is merged then I can revise the current ARIA in HTML pr which would mirror the normative AAM text

[ErickRenteria]

Pushed