Description
Reading through the document, there seem to be cases where "owned by" is meant to be either all descendants (as defined) but there are other places where it is strongly implied "owned by" is a parent/child relationship. Firstly, the definition:
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.
But then if we read menuitem, it says the following:
menuitem (role)
In order to identify that they are related widgets, authors MUST ensure that menu items are owned by an element with role menu or menubar, or by a role group which itself is owned by an element with role menu or menubar.
This last part "or by a role group which ..." doesn't make sense if "owned by" applies to all descendants. If a menu item owns all descendants, it automatically owns a menuitem owned by a group that's a child of the menu. The menuitem even owns it, if it's in a list which is in a grid which is in a header which is in a menu.
And that last part is where I'm starting to have proper concerns. The following seems to be conform to ARIA 1.2:
<div role="menu">
<div role="list">
<div role="header">
<div role="menuitem">
<div role="listitem">Tower of oddly nested roles</div>
</div>
</div>
</div>
</div>Even more explicitly, 9.2 basically says that elements are only supposed to have one owned element:
9.2 States and Properties
2. Correct usage with regard to DOM tree structure, such as an element being owned by more than one other element.
On the other hand, there are places where it matters that "owned elements" aren't just the child elements, but all descendants (or at least, up to a certain level):
If aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API.
In this case, it matters that aria-readonly propagates to the cell of a grid. Although even here it could be argued that aria-readonly shouldn't propagate down into nested grid elements. That propagation is far more pronounced for the presentation role, and here it really matters if "owned elements" is limited to children, or all descendants:
presentation (role)
When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined.
As far as I can tell, browser vendors have taken this to mean all children, and everything directly referenced through aria-owns. That's very sensible, otherwise a single misplaced role="presentation" on the body element could wrack the semantics of the entire page.
Proposal
I think the simplest solution here would be to split the "owned elements" definition, into "owned children" and "owned descendants". That seems to address most of these issues. Additionally, you'd have to do something about "presentation" and "none", make it clear those elements can't "own" anything.
We'd also get an answer on whether or not "generic" should be included in the accessibility tree or not. Browsers don't seem to agree on that.
A final little bonus thing would be to make it explicit that element referenced with "aria-owns" are owned children of the first element with that attribute, and that other elements can not own them.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Status