ARIA 1.2 required owned elements when aria-busy=true

[Zidious]

Ref: https://github.com/dequelabs/axe-core-npm/issues/292

There may be times that required owned elements are missing, for example, while editing or while loading a data set. When a widget is missing required owned elements due to script execution or loading, authors MUST mark a containing element with aria-busy equal to true. For example, until a page is fully initialized and complete, an author could mark the document element as busy.

source: ARIA 1.2 - Required Owned Elements

Example provided:

<div id="while-loading" aria-label="while-loading" role="list">
	<div class="loader" aria-busy="true"><Loading List... /></div>
</div>

Output:

Fix any of the following: Expecting ARIA children role to be added: group, listitem

This results in axe marking this as incomplete. Do we want to assume if a required owned elements is missing but its child has aria-busy=true we pass it? Or better, update the incomplete message to inform the user that we cannot determine if element is accessible due to aria-busy?

[dylanb]

I think we should add comprehensive support for aria-busy where if something has aria-busy set to true we ignore all violations within that element.

[WilcoFiers]

Revisiting this issue, as it is now also relevant for axe-core's consistency with the ARIA required owned elements ACT rule.

I agree with Dylan, although I'm not sure we should try to do this all in one go. I'd prefer we do the required children thing first, and in a later stage figure out what to do with other rules.

Support for aria-busy still seems fairly limited. That's something to consider here as well.

[WilcoFiers]

Idea on how to globally handle aria-busy:

Similar to how reviewOnFail works, we could a mechanism in the Rules class that, if the node or one of its related nodes is itself aria-busy, or has a parent that is aria-busy, have that rule always report violations as incomplete. That could then immediately work on all rules. Perhaps we'd need an option to turn this behavior off per rule, although I can't really even think of an exception to this.

In addressing this issue, I think we should try this out, if it doesn't look too complicated we can pull it into the 4.5 release. If it looks like it'll take a week to build we'll probably do the simpler solution for aria-required-children first, and defer the core solve to a later release.

[dylanb]

I think they should just be ignored rather than generating more incompletes

[straker]

@dylanb the support for aria-busy isn't great (only works in JAWS), so I'm not sure if we want to completely ignore the issues.

[straker]

Instead of a global aria-busy check, we could scope this to only look at required child rules (list, aria-required-children, definition-list). So if the parent element or child has aria-busy we can mark the rule as pass.

[padmavemulapati]

Validated with the latest develop branch code base, reproducing with 4.3.5 version as below: aria-required-children was into incomeplete result as well the the fix details is having Fix any of the following:\n Expecting ARIA children role to be added: group, listitem Now with 4.4.3 , seeing aria-required-children into failure as well fix information as Fix any of the following:\n Element has children which are not allowed (see related nodes)\n Element has no aria-busy=\"true\" attribute With this change it helps aria-busy check

[clamli]

Hi!

It seems that the same code snippet still trigger the aria-required-children

<div id="while-loading" aria-label="while-loading" role="list">
	<div class="loader" aria-busy="true"><Loading List... /></div>
</div>

Is this expected?

[straker]

@clamli I believe the aria-busy attribute must go on the role=list element for this to pass.