RE: Lack of clarity regarding "required owned elements"

"Does this apply to all the complex ARIA widgets (e.g. menu, combobox/listbox, tree, or grid)?"

That's what we need to work out more explicitly.

Personally I think we should say that including embedded active element roles inside of widget roles that are not composite should not be acceptable for these reasons.


From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Monday, April 25, 2016 8:57 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; public-aria@w3.org
Subject: RE: Lack of clarity regarding "required owned elements"

Good point Bryan!
Maybe this is verbiage we need to add to the "required owned elements" section of the spec for clarification purposes.

Does this apply too all the complex ARIA widgets (e.g. menu, combobox/listbox, tree, or grid)?



From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Monday, April 25, 2016 11:44 AM
To: Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: RE: Lack of clarity regarding "required owned elements"

One thing to keep in mind is that certain ARIA roles are meant to be composite widget containers, which support different child element roles as needed.
http://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#composite

As such, like role=tablist, role=gridcell, etc., you can include supporting element structures accessibly if programmed correctly.

An example of this is if you have a role=tablist container that includes a keyboard accessible Delete link associated with each role=tab element.

To ensure correct reading order, these links would need to be included within the role=tablist container, however they cannot be included inside of the role=tab element because this is not a composite widget type.

So the way this works accessibly, is that you can arrow between the role=tab elements, and as focus is set to each role=tab element, tabindex is also toggled on the associated Delete link so that you can simply press Tab from any role=tab element to set focus to Delete and activate it, and none of the others are in the tab order to prevent confusion. Also aria-describedby should be set on the Delete link to point to the ID of the associated role=tab element so that this is announced when it receives focus which also works on touch screen devices.

For this to work though, you need to be able to add these Delete links inside of the role=tablist container as owned elements, even if they are not declared explicitly as such.

The importance of this distinction also, is not to do this within widget roles that are not composite widgets, such as role=button, role=tab, role=treeitem, etc., because this will not work accessibly across devices if done this way.


From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Sunday, April 24, 2016 1:19 PM
To: public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Lack of clarity regarding "required owned elements"

All.

I am working on an automated accessibility test for required owned elements of ARIA roles.
The short version:
Can an element own (or contain) elements with roles other than the required owned element role in addition to owning at least one instance of required role?
e.g.
- Can a tablist own tabpanels in addition to tabs?
- Can a menu own a link or a span in addition to menuitem elements?
My hnuch is no. If I look at the html equivalent, a <ul> tag can only own <li> tags, script tags or templates. If it owns a span, div or a button that fails validation.
But I am not sure enough to write an automated check without further confirmation.

ARIA spec Context:
The required owned elements section (section 5.2.5 of http://www.w3.org/WAI/PF/aria-1.1/roles) states:
"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."

Maybe it is confusion because English is not my native language, but does "any element" at the beginning of that sentence equate to "every element"?

Thanks
-Birkir