Interpreting the "required own elements" section of the ARIA spec

Good afternoon (and a happy weekend) to everyone.

 

I have a question regarding the ARIA 1.1 spec - section 5.2.5, required
owned elements :

https://www.w3.org/TR/wai-aria-1.1/#mustContain

copy of the text:

"Any element that will be owned by the element with this role. For example,
an element with the role 

list will own at least one element with the role group or listitem.

When multiple roles are specified as required owned elements for a role, at
least one instance of one required owned element is expected. This
specification does not require an instance of each of the listed owned
roles. For example, a menu should have at least one instance of a menuitem,
menuitemcheckbox, or menuitemradio. The menu role does not require one
instance of each."

 

My questions:

In addition to owning at least one instance of the required element role,
can the element own elements with a different role?

For instance, can a menu own a menuitem element as well as a link or a form
field?

for example:

<div role="menu">

<span role="menuitem">Item 1</span>

<a href="#">Help for item 1</a>

</div>

My understanding is that all children of an element must have the required
owned element role. This is important for enabling interaction for assistive
technology applications.

An element with an unexpected role in an interactive widget can break the
assistive technology paradigm for that widget (for example by forcing
assistive technology in and out of interactive mode).

But I have difficulty clearly seeing this communicated in the spec.

The closest I get is by looking at the first sentence:

"Any element that will be owned by the element with this role." 

My interpretation is that all children of the element must have a required
own element role, but I am not sure. Neither are some of the developers I
work with.

1. Is my understanding correct, that an element may only own children with a
required owned element role?

2. Can we change the text to state this more explicitly, either by changing
the wording or adding an explanatory note?

When these widgets are coded incorrectly they cannot truly be made
accessible (see my post earlier this week on tabs), so it is hugely
important that the spec leaves minimal room for interpretation.

Thanks

-Birkir