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>
</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>
</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>
  </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>
   ...
</article>

Additional test cases provided here.

[straker]

Thanks for the update. Do you happen to have a timeline for when these changes will go into the spec? The hard part of implementing this is that we don't currently support allowed roles based on the parent tree.

The rest is mostly notes for myself.

Testing out the test cases on current axe-core:

For Test 1 (any role allowed on li when parent list has role none), we mark all elements as not allowing the role.

For Test 2 (any role allowed on li when not parent list), we mark all elements as not allowing the role.

For Test 3 (no role allowed on li when parent element has role list), we do not fail for the following roles:

• "generic" (not a role we support yet)
• "menuitem"
• "menuitemcheckbox"
• "menuitemradio"
• "none"
• "option"
• "presentation"
• "radio"
• "separator"
• "tab"
• "treeitem"

Test 1 and 2 should be the same logic internally (a role of none and a parent that is not a list should be the same), so fixing that should address both cases.

[scottaohara]

@straker @WilcoFiers any additional thoughts on axe accepting the revised allowances noted here? We've had a few instances of this come up lately (e.g., <ul role=none><li role=whatever-cause-it's-fine>...) and it reminded me to check in on this.

thanks