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>; 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