aria-required-parent/children does not respect intermediate group role for list/listitem

[merrywhether]

Product

axe-core

Product Version

4.10.3

Latest Version

• [x] I have tested the issue with the latest version of the product

Issue Description

Expectation

I have the following DOM structure (redacted/simplified):

<div role="list">
  <fieldset>
    <legend>
      <p>List</p>
    </legend>
    <div role="listitem">
      list-item
    </div>
    <div role="listitem">
      list-item
    </div>
  </fieldset>
</div>

Per the ARIA spec, the list > group > listitem structure is valid (fieldset has the implicit role of group).

Actual

After upgrading from 4.8.2 to 4.10.3, I started getting required parent/children warnings (running via jest-axe):

    Expected the HTML [...] to have no violations:
    <div role="list">

    Received:
    "Certain ARIA roles must contain particular children (aria-required-children)"

    Fix any of the following:
      Element has children which are not allowed: [role=group]

  ────────

    Expected the HTML [...] to have no violations:
    <div role="listitem">list-item</div>

    Received:
    "Certain ARIA roles must be contained by particular parents (aria-required-parent)"

    Fix any of the following:
      Required ARIA parent role not present: list

Adding an explicit group role on the fieldset does not fix it (as expected given the first error indicating that it correctly identifies the implicit role). Moving the list role to the fieldset does fix the warning, though that was only for debugging the library and is undesirable for many reasons.

How to Reproduce

Can see the violations logged to the console in this fiddle: https://jsfiddle.net/b3x2npm8/

Additional context

n/a

[straker]

Thanks for the issue. I see you linked to the ARIA 1.1 spec in your description. Axe-core has been upgrading to ARIA 1.2, and ARIA 1.2 removed the allowance of list > group > listitem. The interesting thing about this though is the change to not allow group inside a list was released in v4.6.0, so I'm not sure why you wouldn't see this issue happening on v4.8.2. I ran the provided code in v4.8.2 and I see the issue being reported.