Skip to content

aria-required-children: failures for disallowed child roles shouldn't include an aria-busy message #4340

@dbjorge

Description

@dbjorge

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-busy is almost never the right solution to solving a practical instance of an aria-required-children failure, 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 about aria-busy creating 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

  1. (definite) cases where aria-required-children-evaluate would fail with messageKey 'unallowed' should not consider aria-busy. It shouldn't be an option for passing the rule, and it shouldn't appear in failure messages
  2. (definite) cases where current aria-required-children-evaluate would fail with its default messageKey still consider aria-busy="true" as a means of passing the rule
  3. (more open for debate) cases where aria-required-children-evaluate would fail with its default messageKey should not mention aria-busy="true" in the failure message, despite 2

Actual

  1. Not met
  2. Already met (we should make sure it remains met while addressing this issue)
  3. Not met

How to Reproduce

existing aria-required-children test cases

Additional context

n/a

Metadata

Metadata

Assignees

Labels

false negativerulesIssue or false result from an axe-core ruleungroomedTicket needs a maintainer to prioritize and label

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions