aria-allowed-attr possible regression?

Product: axe-core

Expectation: element with both aria-controls and aria-expanded passes

Actual: element with both aria-controls and aria-expanded fails

Motivation: I believe it might have been an accidental regression via https://github.com/dequelabs/axe-core/blob/develop/CHANGELOG.md#:~:text=aria-allowed-attr%3A check for invalid

axe-core version: 4.3.4

We recently found a test started failing that uses axe-core. We previously had axe-core@4.3.3 installed, where the test passes, the test has started failing since axe-core@4.3.4, which leads me to believe it may have been an accidental regression via this change: https://github.com/dequelabs/axe-core/blob/develop/CHANGELOG.md#:~:text=aria-allowed-attr%3A check for invalid

For context, we have an element with both an aria-controls and aria-expanded attribute, e.g.:

<my-el aria-controls="menu" aria-expanded="false"></my-el>

As far as my accessibility knowledge goes, this should be valid (but I’m happy to be corrected if I’m wrong). I also checked with a couple of colleagues, who also expected this to be valid.

[straker]

A followup on this issue. Axe-core 4.4 (releasing at the end of this month) will add back the violation for non-global ARIA attributes on elements with a role. We have also introduced a fix for custom elements to report as Needs Review rather than a failure.

[thepassle]

TIL, thanks!