RE: Children are Presentational (again) - new information

I agree with both points, the separation of treeitem nodes in this way works very well for backwards compatibility and for implementing menuitems in the same manner where one onclick can be used to configure keyboard functionality on native active elements such as links without requiring key event handlers, which is necessary if using a focusable LI type construct that also has to deal with event bubbling, even though technically both are valid.

James, can you summarize what we spoke of earlier during the APG call? I think we can get this done as we spoke of by enhancing the definition of required owned elements and children presentational to cover the limitted number of widgets that include specific child roles only but no others.

Thanks,
Bryan


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: Monday, June 13, 2016 9:25 AM
To: 'James Nurthen' <james.nurthen@oracle.com>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; public-aria@w3.org
Subject: RE: Children are Presentational (again) - new information

Why do tree nodes have to be children of treeitem notes?
What about:
<ul role=”tree”>
<li role=”presentation”>
  <a href=”#” id=”t1” role=”treeitem” aria-expanded=”false” aria-controls=”treenode1”>Treeitem 1</a>
<ul id=”treeitem1” role=”group” aria-labelledby=”t1”>
<li role=”presentation”>
  <span role=”treeitem” aria-level=”2”>Treenode item 1</span>
</li>
<li role=”presentation”>
  <a href=”#”> tabindex=”-1” role=”treeitem” aria-level=”2”>Treenode item 2</a>
</li>
</ul> <!—tree node -->
</li>
…
<ul> <!—tree -->

Aria-owns can be used on the tree and the group nodes representing tree nodes.
Aria-controls establishes a relationship, but it is strictly speaking not necessary, because the navigation is controlled via Javascript.
The controls/aria-labelledby relationship is used in, and works well with, tabs.
The first tree node is focusable.
-B

From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Monday, June 13, 2016 11:50 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Re: Children are Presentational (again) - new information


Bryan,

Can you please explain how you would create a hierarchical tree if treeitem only allows presentational children.

This is the definition of presentational children

"The DOM descendants are presentational. User agents<https://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#dfn-user-agent> should not expose descendants of this element<https://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#dfn-element> through the platform accessibility API<https://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#dfn-accessibility-api>. If user agents<https://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#dfn-user-agent> do not hide the descendant nodes, some information may be read twice."

So taking this, if my treeitem has other treeitems as children (completely normal in a tree) a useragent should not expose those descendents? This would break every tree.

Regards,

James



On 6/13/2016 12:00 AM, Bryan Garaventa wrote:
So if children are not presentational for widgets that are not logical children in these cases, what are you proposing to happen?

E.G If you allow some based on this logic, what about the following?

<ul role=”menu”>
<li role=”menuitem” tabindex=”0”>
<a href=”http://whatever.com”>My help page</a>
<ul role=”region” aria-label=”Personal Options”>
<li role=”presentation”>
<h2> Options </h2>
<input type=”text” value=”Bryan Garaventa” title=”Full name”>
<button> Edit </button>
</li>
</ul>
</li>
</ul>

I see developers doing stupid things like this every day, and it doesn’t help that the spec is so ambiguous that it actually does not state that this type of thing is not allowed, and it results in totally unusable and inaccessible software.

As I mentioned to Fred, simply not saying that children are presentational for these roles will not solve this problem, because these are not composite widgets according to the spec.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>
415.624.2709 (o)
www.SSBBartGroup.com<http://www.SSBBartGroup.com>

From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Friday, June 10, 2016 12:29 PM
To: public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Children are Presentational (again) - new information


I don't see how we can add children are presentational to

  *   treeitem
  *   menuitem
  *   menuitemcheckbox
  *   menuitemradio

treeitems are allowed to have other treeitems (and groups) as children. As such they cannot have children are presentational set.

In a similar way menuitem, menuitemcheckbox and menuitemradio can own menus, menubars and groups and should also cannot have children are presentational set.
--
Regards, James

[Oracle]<http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[Green Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment

--
Regards, James

[Oracle]<http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
[Green              Oracle]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment