Comment 1 by bgaraventa on 2013-10-13 00:46
As I mentioned in my prior bug, the issue isn't regarding the focusability of an ARIA Tree. I agree that an ARIA Tree must always be focusable. This is the only way to traverse it using the arrow keys as you would with a Windows TreeView control (press Windows+E to see).

Please refer back to the original bug to see what I mean regarding that NVDA does not convey that the control is a TreeView control at all when you arrow down the page in Browse Mode.

Comment 2 by jteh on 2013-10-13 05:37
We know what you mean. When we say the tree itself isn't focusable, we mean the tree itself (the element with role tree) doesn't have a tabindex (-1 would be fine). This means you can't programmatically set focus to the tree. Instead, you have to traverse the tree to find the currently selected item and set focus to that.

Comment 3 by jteh on 2013-10-13 05:39
To clarify further, if you set tabindex="-1" on the element with role "tree", NVDA will behave as you expect. Obviously, this isn't required by the ARIA spec, so we need to find a way to handle trees as expected when there is no such tabindex.

Comment 4 by jteh on 2013-10-15 03:09
While we will need to support this in order to comply with the spec, it's worth noting why I think this aspect of the spec is broken. When a tree is implemented this way, it's impossible to programmatically set focus to the tree itself and have focus move to the correct item. For example, if an NVDA user uses object navigation or a touch screen to move to the tree, they can't simply set focus to it. Instead, if they want to navigate from the currently active item, they have to move through all of the tree's items to find it and then set focus to it. The user gets the correct experience when tabbing, but not if they're navigating via some other means. This could be fixed by setting tabindex="-1" on the tree and having its focus event set focus to the active item. Imo, the spec should have enforced this, but I guess this use case was overlooked.

@jcsteh is this actually still an issue? Or has it been solved somewhere in the past?

Yes, it's still broken. STR:

1. Open this test case:
   data:text/html,<div role="tree"><div tabindex="0" role="treeitem" aria-selected="true">foo</div></div>
2. Press enter on the tree in browse mode.
3. Press NVDA+tab.
   • Expected: NVDA should say "foo tree view item..."
   • Actual: NVDA says "document..."

More complete test case at http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20%28External%20XML%29/demo.htm

Previously, I said:

The only realistic solution I can think of is 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've since realised we can instead call IAccessible::accSelection on the tree, which will return the selected item. That should generally also be a focusable item. We probably just want to render this node into the buffer, which also means the user would know which item is selected without having to enter focus mode. Same for list boxes.

I have a branch geckoVbufRenderSelectedItem in my fork which renders the selected item for list boxes and trees. This fixes this issue, as well as improving the UX for list boxes and trees generally. Unfortunately, I'm being thwarted by two problems:

1. accSelection fails in Firefox with AccessibleHandler enabled. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1514093 .
2. In a <select> with size > 1, Chrome exposes the focusable state on list items, but calling accSelect with SELFLAG_TAKEFOCUS does nothing. As a result, these list boxes never get focused by browse mode. Chrome either needs to support take focus or not expose the focusable state on these items. In the latter case, NVDA will happily walk up to the list and focus that.

CC @michaelDCurran.