aria-busy="true" with descendant invalid ARIA structure

[giacomo-petri]

In ACT Rules CG, a question was raised regarding the correctness of allowing non-well-formed ARIA structures inside a container that has aria-busy="true" (act-rules/act-rules.github.io#2387).

Is aria-busy="true" intended to permit invalid ARIA structures in all cases, only in certain situations, or not at all?

For example, are authors allowed to use the following markup:

<div role="listbox" aria-label="$name" aria-busy="true">Loading...</div>

even though a text node is not an allowed accessible child of the listbox role?

[css-meeting-bot]

March 12, 2026 meeting minutes
Note from Matt: Added link to minutes, which are easier to read than the IRC log.

The ARIA Working Group just discussed aria-busy="true" with descendant invalid ARIA structure.

The full IRC log of that discussion

<Zakim> agendum 5 -- -> aria-busy="true" with descendant invalid ARIA structure https://github.com//issues/2737 -- taken up [from agendabot]
<jamesn> q+
<giacomo-petri> q+
<np-at> q+
<pkra> jamesn: inside aria-busy, what are the rules for invalid aria markup?
<jamesn> q-
<jamesn> q+
<pkra> giacomo-petri: in ACT rules, we allowed everything inside aria-busy
<pkra> ... that seemed to make sense to us but re-reading the spec, it seems uncler.
<pkra> ... e.g. listbox.
<pkra> ... having the text "loading" inside
<pkra> ... in theory, AT should ignore what's inside.
<scott> q+
<pkra> ... but we see developers using the content in, say, a listbox.
<jamesn> Ack gia
<jamesn> Ack np
<jamesn> q-
<jamesn> q+
<pkra> noah: I don't think aria-busy is meant for a loading status, right? You'd still be expected to provide an accessible loader information.
<jamesn> Ack scott
<pkra> ... is it excluded though? If it is, then invalid markup seems fine.
<pkra> scott: I was discussing this with vispero. JAWS treats it like aria-hidden, which makes it pointless. Others don't.
<jcraig> q+ to mention it's intended to suppress required child validation errors during loading states, too. in practice, it varies. Should be testable in WPT soon, so we shouldn't change it until then... NNF™
<pkra> ... this ACT rule feels like a loophole for good and bad actors.
<pkra> ... in manual audits we found lots of aria-busy avoiding invalid markup to show up in automated tests
<pkra> jamesn: if they don't use busy, aria-hidden seems to do the job?
<pkra> noah: but it will throw other errors. I understand Scott's point.
<jamesn> Ack jamesn
<pkra> jamesn: right. But if you can tab to it, then it may or may not be in the tree
<jcraig> ack me
<Zakim> jcraig, you wanted to mention it's intended to suppress required child validation errors during loading states, too. in practice, it varies. Should be testable in WPT soon, so we
<jamesn> Act jcraig
<giacomo-petri> q+
<Zakim> ... shouldn't change it until then... NNF™
<pkra> jcraig: it is also intended to prevent required child errors.
<jamesn> q+ to say there are no required children any more right?
<pkra> ... in practice, it varies whether it's conveyed to the user.
<pkra> ... there were a number of things in ARIA 1.0 that didn't work out or proved not ideal.
<pkra> ... I don't think we should change much unless we can test them. But we have some changes coming that help with that.
<jamesn> Ack giacomo-petri
<pkra> giacomo-petri: by removing the required accessibility children, we alleviate some problems. We already allow no children.
<pkra> ... with aria-busy we have other use cases. E.g. on body.
<pkra> ... in our platform, we treat aria-busy as "everything inside needs manual check". E.g. in body this is obviously important.
<jcraig> https://w3c.github.io/aria/#aria-busy
<pkra> ... with the current ACT rule, we cannot expect any check.
<jcraig> If changes to a rendered widget would create a state where the widget is modifying Allowed Accessibility Child Roles during script execution, authors MAY set aria-busy to true on the widget during the update process. For example, if a rendered tree grid required a set of simultaneous updates to multiple discontiguous branches, an alternative to replacing the complete tree element with a single update would be to mark the tree busy while each
<jcraig> of the branches are modified.
<pkra> jcraig: in the quote from the spec before the tables seems to handle some of this.
<pkra> jamesn: we'd need to look into the blame to check.
<pkra> jcraig: I think that was the context of that change.
<pkra> jamesn: we may find that it might be less useful nowadays.
<pkra> ... but as Scott pointed out this does get misused to suppress errors. Though I think developers may always find some way to do that.
<pkra> noah: we could also allow for an explicit naming when using aria-busy. That might help to identify misuse.
<giacomo-petri> q+
<pkra> jamesn: I'm not sure how useful testing is while there's an aria-busy state.
<giacomo-petri> q-
<jamesn> Ack me
<Zakim> jamesn, you wanted to say there are no required children any more right?
<jamesn> agenda?
<pkra> jamesn: if anyone wants to try a PR, feel free.
<pkra> ... perhaps the last paragraph can be improved.
<pkra> giacomo-petri: I can try but I would make it permissive, right?
<pkra> jamesn: right. And perhaps aria-busy is a problem if it persists.
<pkra> zakim, end meeting