#16323 closed task (fixed)
Tree: reuse key navigation code in _KeyNavContainer
Reported by: | bill | Owned by: | bill |
---|---|---|---|
Priority: | undecided | Milestone: | 1.9 |
Component: | Dijit | Version: | 1.8.1 |
Keywords: | Cc: | mikeb, cjolif | |
Blocked By: | Blocking: | #16589 |
Description
[29912] essentially duplicated the letter key navigation code from Tree into _KeyNavContainer. Reuse that code from Tree to remove the duplication.
Change History (25)
comment:1 Changed 8 years ago by
Milestone: | tbd → 1.9 |
---|---|
Status: | new → assigned |
comment:2 Changed 8 years ago by
comment:11 Changed 8 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Starting with r30029, Tree TAB navigation isn't correct. Using test_Tree.html, focus China, then tab out and then back into the Tree widget and China is no longer focused.
comment:12 Changed 8 years ago by
Blocking: | 16589 added |
---|
comment:13 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
As explained in the checkin comment to [30029]:
The only behavioral change is that when you tab into the Tree, it always goes to the first node, rather than the previously focused node.
So, this is expected behavior, is consistent with the way widgets like Toolbar and MenuBar have always worked, and actually fixes a few bugs (see #6236), such as when the China tree item is deleted, or the Asia tree item is closed, making China unfocusable.
I don't see how this new behavior can be considered incorrect.
comment:14 Changed 8 years ago by
Cc: | mikeb added |
---|
I think 1.8 is compliant with WAI-ARIA standards and trunk is not:
http://www.w3.org/WAI/PF/aria-practices/#Site_Navigator_Tree
Focus: When the tree receives focus, the item in the tree that is marked as currently displayed should receive focus.
I think this should be fixed.
comment:15 Changed 8 years ago by
Hmm, well that's about a "Site_Navigator_Tree", which is why it's talking about "the item.. that is marked as currently displayed", a concept which has no meaning to a plain tree.
Also, if a Tree were used to implement site navigation, then according to that spec, shouldn't tabbing into the Tree send focus to the currently selected node, rather than the most recently focused node? They aren't necessarily the same because the user might have used the arrow keys to change the focus TreeNode without ever pressing ENTER to select it.
PS: Assuming an app had a tree where one item is always selected (as opposed to no selected items, or multiple selected items), they could easily change Tree.focus() to focus that item. Not sure if the logic belongs in Tree itself.
comment:16 Changed 8 years ago by
Thinking about this from a keyboard user's standpoint, I'd be really annoyed if I navigated to the middle of a tree and then tabbed out to go do something else and when I tabbed back into the tree I had to re-navigate to the middle of the tree again to get back to where I was when I left. Also, if you look at http://www.w3.org/WAI/PF/aria-practices/#TreeView it is about a hierarchical list. It has a similar requirement to the Site Navigator tree: "The last visited node in the tree control is retained in the tab order when the user navigates away from the tree control."
Yes, there could be situations where the focused node could be deleted. But, deleting the node should go through some sort of code within the tree control and if the node being deleted has a tabindex==1, then the focus gets set to the first node in the tree. The same would go for closing a node - check that none of its children has focus. I thought these behaviors were implemented in the tree control at one point.
comment:17 Changed 8 years ago by
I agree with the comments about returning a user to a previously focused node when re-entering a tree. It's epically important when a tree contains many nodes. Returning a user to the first node would be a serious usability concern.
comment:18 Changed 8 years ago by
Is there something special about Tree, besides likely having more items? As I said before, Toolbar and MenuBar focus the first child too, and no one has complained about them... plus a Menu on the side of the screen is very similar to a site navigation tree, except I guess without the concept of a selected item.
Also, as I said above, both http://www.w3.org/WAI/PF/aria-practices/#TreeView and http://www.w3.org/WAI/PF/aria-practices/#ListBox suggest to focus the first selected node, rather than the previously focused node, and that's also what TabContainer does. Tree and Menu are a little bit different since there's usually no selected node, although Trees do have that ability.
comment:19 follow-up: 20 Changed 8 years ago by
Cc: | cjolif added |
---|
Windows Explorer has a tree of directories on the left and a list files on the right and you can tab back and forth, and navigate with arrow keys the same as with the Tree widget. It would be bad if it resetting the left side list of directories whenever you tab back. I also checked Rational Team Concert which uses tree constructs for nearly everything and it always focuses the previously focused item when you tab back and forth. I think trees are considered different because it can take considerable effort to navigate to a specific place within a large set of nodes and because it's common for another pane to render based on the current Tree context. I think this should block 1.9 alpha.
comment:20 Changed 8 years ago by
Replying to doughays:
Windows Explorer has a tree of directories on the left
Actually, Windows Explorer's tree is an example of a Site_Navigator_Tree, and like I mentioned in comment:15 and comment:18, tabbing into the tree goes to the selected node, not the most recently focused node as you are requesting. You can confirm this by typing a new path in the "Address" bar, for example "C:\", and then tabbing into the tree.
Having said that, I agree that remembering the last focused node is useful for a Tree without a selection, and other widgets like Grid, so I'll add that if you want.
In [29979]: