-
Notifications
You must be signed in to change notification settings - Fork 850
Description
Product
axe-core
Product Version
4.8.4
Latest Version
- I have tested the issue with the latest version of the product
Issue Description
When aria-required-children fails due to an element containing a disallowed child (as opposed to not containing a required child), the aria-busy check still runs separately.
This is problematic for two reasons:
- (common, we've seen confusion about this) It makes the error message confusing. Adding
aria-busyis almost never the right solution to solving a practical instance of anaria-required-childrenfailure, but because it's a separate check, it contributes to the failure summary as a viable top-level option. - (uncommon) It would create a false negative if an element contained disallowed children but also listed
aria-busy="true". The relevant bit of aria spec that talks aboutaria-busycreating a Required Owned Element exemption only allows required elements to be missing.
@straker noted this in #3934 (comment), but it looks like the comment got lost without being addressed when a PR resolved.
I think the right way to resolve both issues is to just fold the aria-busy logic into the main aria-required-children-evaluate function - the logic is pretty minimal and only used in this one rule. That way we can defer the aria-busy check only to the path where required children are missing. I think even in that case, it'd probably be preferable to omit mention of it from failure messages - failure messages don't necessarily need to note every edge case we handle, and I think it causes more confusion than it helps for the message to mention aria-busy even in cases where it would create an exemption.
Expectation
- (definite) cases where
aria-required-children-evaluatewould fail with messageKey'unallowed'should not consideraria-busy. It shouldn't be an option for passing the rule, and it shouldn't appear in failure messages - (definite) cases where current
aria-required-children-evaluatewould fail with its default messageKey still consideraria-busy="true"as a means of passing the rule - (more open for debate) cases where
aria-required-children-evaluatewould fail with its default messageKey should not mentionaria-busy="true"in the failure message, despite 2
Actual
- Not met
- Already met (we should make sure it remains met while addressing this issue)
- Not met
How to Reproduce
existing aria-required-children test cases
Additional context
n/a