RE: Prior to filing ARIA 2.0 bug for structural elements not processing owned children within the accessibility tree

Yes indeed, this is the same issue.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Tuesday, July 19, 2016 12:10 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; public-aria@w3.org
Subject: RE: Prior to filing ARIA 2.0 bug for structural elements not processing owned children within the accessibility tree

A different version of the same problem is when a structural role is applied to the parent, the children are still alive and well.
Consider:
<ul role=”menu”>
<li><a href=”#” role=”menuitem”>Menu item 1</a></li>
<li><a href=”#” role=”menuitem”>Menu item 2</a></li>
</ul>

The assistive technology still announcedsindividual menu items as “1 of 1” because of the <li> role, so role=”presentation” is required on those roles to really wipe out the remaped list markup.
I believe this is true in all user agents/a.t. combinations I have tested with.
It is hard to ssay with Jaws, because Jaws does not automatically announce the number of children.

It shouldn’t be needed.
If the ul element is mapped as something else, its child <li> elements should be made presentational.
-B
This might be different enough to warrant its own issue, but I think the root cause is the same.