ARIA required owned elements (bc4a75): Elements should be allowed children _not_ required by their role

[kasperisager]

The rule currently states, emphasis mine:

Each test target only owns elements with a semantic role from the required owned element list for the test target's semantic role.

At Siteimprove, we've however seen quite a few cases of patterns like the following:

<div role="radiogroup" aria-label="Search options">
  <input type="radio" id="restrict">
  <label for="restrict">English</label>

  <input type="radio" id="university" checked>
  <label for="university">University</label>
</div>

In Alfa, the above results in the following accessibility tree:

radiogroup "Search options"
  text " "
  radio "English"
  text " "
  element "English"
    text "English"
  text " "
  radio "University"
  text " "
  element "University"
    text "University"
  text " "

This aligns well with the accessibility tree constructed by Firefox:

For some reason, Chrome decides not to expose the <label> elements, though I don't see any support for this decision in the Core AAM. If I add an explicit role of label to both elements, they are however included.

Either way, the problem is that this to me perfectly reasonable pattern fails the rule as the two <label> elements are not required children of the radiogroup role. If we also consider implicit semantics, which Alfa does as mentioned by @Jym77 in #1413 (comment), the following case is also troublesome:

<table>
  <caption>This is a table</caption>
  <tr>
    <td>This is some data</td>
  </tr>
</table>

Because of this, it seems best to change the expectation of the rule to only require that at least one required owned element is present. Thoughts?

[WilcoFiers]

That makes sense. Do you want to put together the pull request?

[kasperisager]

Sure 👍

[WilcoFiers]

@kasperisager Thinking about this some more... changing this means empty containers would no longer be allowed. I suspect that is going to create issues on the other side. Maybe we should make this conditional, have it only be applicable to elements with palpable content?

[kasperisager]

That's true 🤔 It would require empty containers to specify aria-busy=true, which doesn't necessarily seem reasonable. For the first case you listed in w3c/aria#1033 (comment) it would mean that the empty <ul> would need to be "busy", which it really isn't. It's just, well, empty 🤷

[kasperisager]

To take the opposing view as well, requiring aria-busy=true on empty containers might actually be appropriate considering the intended handling of busy elements:

When aria-busy is true for an element, assistive technologies MAY ignore changes to content owned by that element and then process all changes made during the busy period as a single, atomic update when aria-busy becomes false.

So, until a user has added some todos to the list, AT should hold off on announcing it. Then, perhaps when the user removes focus from the text input, the added todos can be announced as a single, atomic update.

[WilcoFiers]

Not too sure about that. aria-busy is to indicate to AT that the component is being updated. That isn't really the case about an empty list. It's just empty. We thought of putting that into axe-core too, do it based on aria-busy, but that seems like it's a bit of a stretch on what the intended purpose of aria-busy is.

[kasperisager]

I'm also not entirely convinced that it'd be appropriate. I'd really like for the ARIA WG to clarify this though, because I'm beginning to doubt if the concept of "required owned elements" even makes sense. If the logic ends up becoming "if the element owns at least one other element then at least one of the owned elements is of a required role" then I'm not sure if the rule is really providing any value 🤔

[WilcoFiers]

I pinged James on Slack this morning about it, to try to get a reaction on my open issue in the ARIA repo.

[kasperisager]

The need for this came up again in #1552. Is there any news from the ARIA WG?

[WilcoFiers]

This isn't getting addressed until ARIA 1.3. The ARIA spec needs to clarify the intent of required owned elements, before we can do much with it in ACT.