axe-core: False positive in aria-required-children "unknown" path for child not in accessibility tree with aria-hidden="true"

Product

axe-core

Product Version

4.6.2

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Expectation

The following pattern should not result in an aria-required-children failure:

<div role="menu">
  <div role="menuitem">menu item</div>
  <div aria-hidden="true">shouldn't be flagged but is</div>
</div>

Actual

This results in a failure with the following failureSummary:

Fix any of the following:
  Element has children which are not allowed (see related nodes)
  Element has no aria-busy="true" attribute

How to Reproduce

Minimal repro (+ an example where the same case without aria-hidden="true" does not trigger the failure)

Additional context

Per #3462, the “unknown” failure path introduced in aria-required-children in #3597 attempts to detect cases similar to this ACT rule’s “failed example 3”, where a child in the accessibility tree (emphasis mine) does not have a role that matches one of the requiredOwned roles for the parent.

However, we think the logic introduced in #3597 to determine whether a child is “in the accessibility tree” for the purposes of this rule is a bit off - it does so by asking “does the child have any global ARIA attribute OR is it focusable”. However, aria-hidden is a global ARIA attribute which currently triggers the first clause of this check, which is inconsistent with the rule. Per the glossary of the ACT rule in question, an element which is programmatically hidden should be treated as “not included in the accessibility tree” for the purposes of this check:

Included in the accessibility tree

Programmatically hidden elements are removed from the accessibility tree. However, some browsers will leave focusable elements with an aria-hidden attribute set to true in the accessibility tree. Because they are hidden, these elements are considered not included in the accessibility tree. This may cause confusion for users of assistive technologies because they may still be able to interact with these focusable elements using sequential keyboard navigation, even though the element should not be included in the accessibility tree.

Right now, even a non-focusable child whose only global ARIA attribute is aria-hidden="true" causes a failure, which I think is pretty firmly a false positive. The wording of the ACT rule as written suggests that a programmatically hidden child should not trigger a failure even if it is focusable - I think it would be reasonable to flag that as a best-practice level warning anyway, but I think the non-focusable case clearly shouldn’t fail.