owned elements definition

[WilcoFiers]

WAI-ARIA 1.1 defines owned elements like this:

Owned Element

An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.

There is an obvious flaw in this, that it contradicts native semantics and plain logic. Here's an example:

<ul id="l1">
  <li>Item 1
    <ul> <li>item 1 A</li> </ul>
  </li>
</ul>

List #l1 according to ARIA has 2 "owned" listitems. Despite that, no browser/assistive technology out there announces this as a list of 2 items. You can change the uls to a div[role=list] and the lis to div[role=listitem] and the problem stays the same. That strongly suggests to me that this definition is wrong, and that Auto-WCAG should not use it.

There is also the following case:

<ul id="l2">
  <li>Item 1</li>
  <div>Item 2</div>
</ul>

Should #l2, be counted as having two items? Many browsers do today do this. They do not look at the role when deciding the size of a list. We need to do more research on this, but it might mean that the listitem role is superfluous, and requiring it would not be necessary.

[mfairchild365]

With regards to #l1: HTML-AAM for an li with a parent <ol> or <ul> says:

"listitem role with aria-setsize value reflecting number of li elements within the parent ol or ul and aria-posinset value reflecting the li elements position within the set."

Perhaps the key in this specific mapping is that it is referencing the "parent" <ol> or <ul> and not the 'owned element'.

With regard to #l2: CORE-AAM 5.6.4 Group Position states that

Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role.

So I would think that its a bug if browsers are including the <div> in that count because it has a different role than the <li>. This smells of a browser trying to guess what the autor meant.

Another, similar question is: how should this example be computed:

<ul id="m1" role="menubar">
    <li id="li1">
        <a id="mi1" role="menuitem" href="#">Apples</a>
    </li>
</ul>

What are user agents supposed to do with #li1 in that example? A listitem has a required context role ofgroup or list. Technically, the the #m1 now has a role of menubar, which has a superclass role of group. Are user agents expected to include both #li1 and #mi1 in the set count? Does #m1 own both #li1 and #mi1?

[mfairchild365]

For whatever it is worth, I added some test cases to my a11ysupport.io project for the #l1 case. I only had time to test with two screen reader / browser combinations, but they seem to support my HTML AAM interpretation.

https://a11ysupport.io/tech/html/li_element

I decided to not add test cases for the other examples here because I don't want to list/encourage test cases built around non-standard and potentially invalid HTML.

[WilcoFiers]

Next action: Research how browsers come up with owned elements and what the differences are, so that we can come up with a definition that works relatively well across different browsers.

[annethyme]

Agreed on Auto-WCAG meeting that these are the steps moving forward:

1. Collect test cases in this thread (@WilcoFiers will contribute some)
2. @JKODU and @annethyme collect test cases within the next couple of weeks
3. @WilcoFiers will find someone to test it in browser/AT combinations
4. We write a definition of "owned elements" as we see it
5. We contribute our findings to the WAI-ARIA group and AOM group.

[WilcoFiers]

Created a codepen for testing here owned elements here:
https://codepen.io/wilcofiers/pen/OaEYKd?editors=1000

[annethyme]

@WilcoFiers, is it correctly understood that that your testers are on this now, and we are waiting for them to get back to us? (cc: @JKODU)

[WilcoFiers]

It's one day late, nevertheless, I think I have a solution for our owned elements problem. I have done a lot of research about this, and I think I have a proposal.

Proposal

This proposal includes 2 definitions. I choose to define how to determine the "owner" rather than how to determine the "owned" elements (and their order) as this is a far easier definition to write, and that's all we'd need for Auto-WCAG rules.

Node in the accessibility tree

Any DOM node in the flattened DOM tree that meets the following criteria is a node in the accessibility tree:

1. It isn't hidden through ARIA or CSS, and
2. It does not have a semantic role of none or presentation, and
3. it has one or more of the following:

• It has a semantic role, or
• It has an accessible name that, when trimmed of whitespace, is not an empty string, or
• it owns another element though an aria-owns attribute, or
• It is owned by another element that references it with aria-owns

Note: Text nodes and pseudo elements can also be part of the accessibility tree, since they have their text content as the accessible name.

Owner element

The owner of a node in the accessibility tree can be determined by checking:

1. if the node is referenced by an element through aria-owns
   The owner is the first node in the DOM tree that references it through aria-owns
2. Otherwise,
   The owner is the closest ancestor that is a node in the accessibility tree

Nodes that are not in the accessibility tree do not have an owner element.

Research details

In coming up with this research I've tested a lot of browser and screen readers.

• IE and Edge do not look at owned elements when determining the set size (for lists, menus, etc.), instead only counting elements with the correct role.
• Safari, Edge and IE do not support aria-owns
• Firefox includes elements without a semantic role in the accessibility tree, where as Chrome and Safari only seem to do so if those nodes have an accessible name or aria-owns. The Chrome / Safari solution seemed to me like the smarter way to do it.

Plans for adoption

Firstly, what I am proposing is what I believe should be the definition of an owned element. This is not spec'ed out anywhere. If the Auto-WCAG group thinks this is a sensible proposal, I want to share it with the ARIA working group and the folks working on AOM, to see if we can get them to adopt it. I have had talked with them about the topic already, and they seem open to standardising this part of the accessibility tree.

If we agree that this definition is how it should be, then we'll need to make a second decision on if we want to adopt this definition in any of our rules already before any standardisation work has happened. That needs to be a separate question, in order for us not to confuse the "standardisation" question with the "writing rules" question.

@kasperisager @JKODU I'd love your feedback.

[gianwild]

Sounds reasonable to me. Cheers, Gian

[WilcoFiers]

Made a few changes. @kasperisager do I take your thumbs up as a full agreement?

[kasperisager]

@WilcoFiers Without having done much research myself, I do agree with the proposed definitions. They seem very sensible and are not far from how I would intuitively expect things to work. Kudos!

[annethyme]

I have updated the definition and rule for #255.
Please review so that we can get this moving again :)

@WilcoFiers especially, since you have looked most into this.

[jeeyyy]

Given #255 and #245 are moving forward. The above definitions are in place in the PR's. Closing the issue.