Attachment technical_style_guide.zip added by bgaraventa on 2013-02-22 19:57
Description:

Comment 1 by jteh on 2013-02-24 03:07
We should be treating trees the same way as we treat lists; i.e. only rendering the container in browse mode.
Changes:
Milestone changed from None to 2013.2

Comment 3 by James Teh <jamie@... on 2013-05-08 07:15
In [3084070]:

When navigating in browse mode in Mozilla applications, don't switch to focus mode when the cursor hits a hierarchical list.

In Mozilla 23, selects with optgroups are now hierarchical instead of flattened (MozillaBug:809338), so there might be several grouping ancestors between a list item and its containing list.
VirtualBufferTextInfo._getOffsetsFromNVDAObject now accounts for this.
This change will also help tree views when better browse mode support for those is implemented. Re #3023.

Comment 4 by James Teh <jamie@... on 2013-05-08 10:09
In [b5d9e9a]:

In browse mode, the content inside tree views is no longer rendered, as a flattened representation isn't useful. You can press enter on a tree view to interact with it in focus mode.

Fixes #3023.

Changes:
State: closed

Comment 5 by bgaraventa on 2013-10-10 23:57
This issue still occurs as originally documented, and I've confirmed it in Win XP Pro and Win7 using the latest release of NVDA in Firefox.

An example can be tested at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20%28External%20XML%29/demo.htm

When arrowing down the page, nothing other than the word "clickable" indicates that this is an ARIA Tree, so it is impossible for an NVDA user to identify that this is supposed to be a Tree control.
Also, after expanding a branch and reactivating Browse Mode, arrowing back down the page shows all items as a flat list, and not the currently selected item identified by aria-selected=true, so it's not possible to identify which node is currently selected as a result.
Changes:
State: reopened

Comment 6 by mdcurran on 2013-10-11 05:04
I can't reproduce the problem with all nodes being rendered together. However, the major issue here is that the treeview itself is not focusable. At the moment NVDa is expecting (just like lists) that the treeview be focusable in order to allow you to press enter on it to get to focus mode. It being focusable will also solve the problem of it not announcing its a treeview.
It can be debated whether or not NVDa should expect the treeview to be focusable, though other widgets such as lists seem to do this.
Perhaps a tabIndex could be given to the treeview itself, and the ARIA active decendant set as the active item in the tree.
Jamie might have more to say on this.

Comment 7 by jteh on 2013-10-11 06:28
From what I can see, the ARIA spec doesn't specifically say trees have to be focusable. This seems odd to me; normally, you can set focus to a container and focus will move to the focused descendant, if any. Fixing this would require us to walk through the entire tree to find the currently focused item when you press enter on the tree, which is pretty slow and ugly.

I'm spinning this off into a new ticket (#3573), as this fix has already landed in a release and it does work for focusable trees.
Changes:
State: closed

Comment 8 by bgaraventa on 2013-10-13 00:40
I don't understand what you mean that it's not focusable. The ARIA Tree is and has always been focusable.

As referenced above:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20%28External%20XML%29/demo.htm

Go to the top of the page and press Tab. Focus will be set on the Tree.

The issue here is not that you can't set focus to it, the issue is that NVDA does not convey that this is a TreeView control when arrowing down the page in Browse Mode, nor does it reflect which element is currently selected.

If you test this in JAWS 14 in Firefox, you will se how such a control as this is supposed to act.

Comment 9 by bgaraventa on 2013-10-13 01:06
For example, when viewing the same page in Firefox using JAWS 14, in Virtual Cursor mode, start at the top of the page and arrow down the page.

You will hear that the ARIA Tree is only represented on one line, as one form field, and states the following:

"ACT I TreeView Item Selected Collapsed, 1 of 4"

Which conveys the role of the field, "TreeView", the state of the currently selected node "Item Selected" via aria-selected="true", the branch state when applicable "Collapsed" or "Expanded" which reflects the aria-expanded attribute, and the "X of Y" positioning value which is conveyed using aria-posinset and aria-setsize.

If you try the same using NVDA in Browse Mode, you will not hear any of this information.

This is still an open bug.

Comment 10 by mdcurran on 2013-10-13 22:38
Pretty sure that the active item in the tree gets focus, not the tree itself. This is a very important difference.

I understand what you mean about it not announcing treeview, but, the current situation is that NVDA is expecting the tree to be focusable which it is not... even if one of its items may be.

Comment 11 by bgaraventa on 2013-10-14 06:22
I'm sorry, but that's not true.

Please read the ARIA spec at
http://www.w3.org/TR/wai-aria/roles#tree

Where it states:

"To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus."

There are only two ways to make an ARIA Tree accessible, and yes, one of these ways is by setting focus on the container with role=tree. This requires the use of the aria-activedescendant attribute and a completely different keyboard handling model.

The second way, which is also totally valid, is to set focus on the individual nodes that include role=treeitem, which is how the ARIA Tree that I referenced is programmed.

The benefit of using the method of setting focus on the treeitem nodes individually instead of setting focus on the container with role=tree in combination with aria-activedescendant, is that doing so works accessibly going as far back as JAWS 11 in IE8.

This method also works well in NVDA using both IE and Firefox when focus is set on the selected tree node, as you've already seen.

The problem is that, when you are arrowing down the page in Browse Mode, you have no way of knowing that you are looking at an ARIA Tree.

Comment 12 by jteh on 2013-10-14 06:33
As I've already stated, we're very much aware what the ARIA spec says about this. We're trying to explain why your particular tree (as opposed to others which set a tabindex on the tree itself) doesn't work in NVDA. We're not trying to say that NVDA's behaviour is correct according to spec; it isn't. This aspect of the spec is a major implementation problem for ATs - you can't programmatically set focus to the tree itself because of it - but regardless, it's part of the spec, so we need to find a way to support it. Unfortunately, we haven't worked out an efficient way to do that yet, which is why I opened #3573.

Comment 13 by bgaraventa on 2013-10-14 20:23
Thank you, I understand, and I really appreciate it.

One of the things that confused me was
"the current situation is that NVDA is expecting the tree to be focusable which it is not... even if one of its items may be."

This looked to me like the intended functionality was that NVDA would only support one method for implementing an ARIA Tree, which would cause compatibility issues down the road.

For instance, at http://www.w3.org/TR/wai-aria/usage#managingfocus
Where it states: "When the container or its active descendant has focus, the user may navigate through the container by pressing additional keys, such as the arrow keys, to change the currently active descendant."

As I've said before, this functionality already works great in NVDA when focus is set on the tree, so it already works perfectly from the keyboard in both IE and FF.

It would be great to see the same level of feedback supported in Browse Mode as well when simply arrowing down the page, so that the control type is accurately conveyed.