RE: Update tree view examples for review on Monday APG call

The core of the problem is that we need ARIA to communicate enough info to assistive technologies so they can expose it in an organized, predictable, and operable way to the end users.

This imposes certain requirements on how elements and structures are mapped to ARIA, and restrictions on how these elements can be implemented by developers.

 

If we make ARIA too permissive for the benefit of developers, the assistive technologies cannot expose it to end users, and then the ARIA markup is of little benefit. This has caused some accessibility experts (yours truly not included) to advise against the use of ARIA. The most recent article exchange around problems with tabs is an indication of the mix of attitudes out there.

But it is true, if ARIA is too flexible or too vague to be translated into a positive assistive technology user experience, we need to take a closer look.

 

Applying this logic to treeitems:

If a treeitem can have one ore more descendants, some static, some operable, how is assistive technology to know that, and how can it expose that information to end users in a manner they will understand?

If there are descendants, how can I, as a user, navigate to those descendants?

My Windows-based experience is that I use arrow keys to expand and collapse tree nodes and the enter key to activate a tree node (e.g. putting focus on the first file or subfolder in a folder).

When I see a tree on a webpage, I anticipate equivalent behavior unless I am provided with additional information.

If we want to invent a more flexible tree widget, we need to discuss how, which might include adding new ARIA attributes that can be added to communicate additional info to the assistive technology / a.t. end user experience.

 

I suggest that we recode the tree widget:

The root <ul> has role=”tree”.

<ul> elements that represent tree nodes have role=”group” (preferably with aria-labelledby pointing to the tree item element used to expand them).

All <li> elements have role=”presentation” (technically it shouldn’t be needed if the <ul> elements have been mapped to a different role, but we need it still for a.t. compatibility).

*       The descendant element of the <li> (links/spans) have role=”treeitem” and associated ARIA attributes as needed.

That way tree nodes are not owned by tree items (which also eliminates the issue of the accessible name and enables children to be presentational).

 

I admit to being a relative newbie in this area, so maybe my proposal here has significant flaws. If so, I’m always happy to learn.

 

From: Fred Esch [mailto:fesch@us.ibm.com] 
Sent: Friday, June 10, 2016 3:53 PM
To: Gunderson, Jon R <jongund@illinois.edu>
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Subject: Re: Update tree view examples for review on Monday APG call

 

Jon,

I think this is bogus explanation. At line 428 of treeview.js a click event is created and the script has the <a> element dispatch the event. If you look at the path array in the event when debugging on line 445, the [0] member (or source) is the <a> element. In other words, the <a> element is a source for an event. Since the <a> element is a source of an event, the <a> element should be in the accessibility tree.

If you are suggesting folks should do JavaScript gymnastics to comply with ARIA, then I think we need to rewrite ARIA so clean HTML and JavaScript is allowed. 


Regards, 

Fred Esch 
Watson, IBM, W3C Accessibility




Watson Release Management and Quality 



"Gunderson, Jon R" ---06/10/2016 03:13:15 PM---Fred, In the following tree view example I see the links as the “action” of the tree, so you cannot

From: "Gunderson, Jon R" <jongund@illinois.edu <mailto:jongund@illinois.edu> >
To: Fred Esch/Arlington/IBM@IBMUS
Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Date: 06/10/2016 03:13 PM
Subject: Re: Update tree view examples for review on Monday APG call

  _____  




Fred,

In the following tree view example I see the links as the “action” of the tree, so you cannot “tab” to the links, and the links do not receive keyboard “focus” (e.g. There DOM parent does), but the link is activated when you press the “space” or “enter” key. 

https://rawgit.com/jongund/aria-practices/master/examples/treeview/treeview-2.html

I think this a popular way to make a treeview that has a link action.

In this example the links essentially act “presentational" since they are only defining what will happen if you activate one of the tree items. 

But the links would still come up in a list of links for a screen reader and would be identified as links in review mode.

Are you suggesting we should add role=none to the links (e.g. A elements) in the example?

Jon


From: Fred Esch < <mailto:fesch@us.ibm.com> fesch@us.ibm.com>
Date: Friday, June 10, 2016 at 1:51 PM
To: Jon Gunderson < <mailto:jongund@illinois.edu> jongund@illinois.edu>
Cc: Accessible Rich Internet Applications Working Group < <mailto:public-aria@w3.org> public-aria@w3.org>
Subject: Re: Update tree view examples for review on Monday APG call

Jon,

One thing that has been discussed recently is whether an element with role treeitem may only have presentational children. And in your example you have a <li> element with role treeitem and a descendent <a> element with a href. As far as I can tell, an  <https://urldefense.proofpoint.com/v2/url?u=http-3A__w3c.github.io_html_dom.html-23interactive-2Dcontent&d=CwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=9XSHXCdKauc14xDCFdL0HX1AhpUTxhNdpgkmIvUdvQs&s=-vtu6jbj5fzpxzCQ_M9Qjydn8CDujA7ZwkqL5VtGoEQ&e=> <a> element with a href is interactive content. So my interpretation is the <li> element with the role treeitem does not have only presentational children. What am I not understanding? Is a <a> element with a href presentational? Or do you not believe that a element with a role treeitem should not be restricted to only have presentational children? 


Regards, 

Fred Esch 
Watson, IBM, W3C Accessibility




Watson Release Management and Quality 



"Gunderson, Jon R" ---06/10/2016 01:41:10 PM---Matt, James and Michiel, Here are the updated tree view examples based on the APG discussion this we

From: "Gunderson, Jon R" < <mailto:jongund@illinois.edu> jongund@illinois.edu>
To: Matt King < <mailto:a11ythinker@gmail.com> a11ythinker@gmail.com>, James Nurthen < <mailto:james.nurthen@oracle.com> james.nurthen@oracle.com>, Michiel Bijl < <mailto:michiel@agosto.nl> michiel@agosto.nl>
Cc: "'ARIA Working Group'" < <mailto:public-aria@w3.org> public-aria@w3.org>
Date: 06/10/2016 01:41 PM
Subject: Update tree view examples for review on Monday APG call

  _____  




Matt, James and Michiel,

Here are the updated tree view examples based on the APG discussion this week, hopefully can discuss changes on Monday’s call.

 <https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_jongund_aria-2Dpractices_master_examples_treeview_treeview-2D1.html&d=CwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=9XSHXCdKauc14xDCFdL0HX1AhpUTxhNdpgkmIvUdvQs&s=_xn1WSVEruh6z5z_2UxUJC_iSCYKjIxnqGfmAk_kbtI&e=> https://rawgit.com/jongund/aria-practices/master/examples/treeview/treeview-1.html 
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__rawgit.com_jongund_aria-2Dpractices_master_examples_treeview_treeview-2D2.html&d=CwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=9XSHXCdKauc14xDCFdL0HX1AhpUTxhNdpgkmIvUdvQs&s=fYh9f9cP92ZEWAGz5vvxAu_mVroUc1ZG389IeKR-ovk&e=> https://rawgit.com/jongund/aria-practices/master/examples/treeview/treeview-2.html

The changes include:
1. Adding a description of the example after the title
2. Updating the keyboard support to match authoring practices
3. Added section on synchronization of visual and aria states
4. Added aria-level, aria-setsize and aria-posinset information to examples

Still todo:
1. Using character to navigate visible tree items
2. Using ‘*’ to open all descendant leaves of the current treeitem

Jon




[attachment "0A236870.gif" deleted by Fred Esch/Arlington/IBM] [attachment "graycol.gif" deleted by Fred Esch/Arlington/IBM]