axe-core: 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.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 16 (10 by maintainers)
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.
TIL, thanks!
ARIA in HTML lists which ARIA roles and attributes are allowed on what elements. For custom elements, the allowed ARIA attributes are any global ARIA attribute and any allowed attributes defined by the
role. Since the element has norole, only global ARIA attributes are allowed.The ARIA spec will list which attributes are allowed on which roles, and also lists the global ARIA attributes.
@thepassle Do you have a real-world example of this? I’m interested to see what those custom elements you’re using non-global ARIA attributes look like. My understanding of this is that sticking attributes like that on custom elements will create problems. I’m curious to see if/how you may have managed to avoid the issues of that.
I take that back, I don’t think that should have been released quite yet, but it seems we released something from develop that shouldn’t have been there yet. Will confirm.