New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browsing down the page using the arrow keys is non-intuitive when an ARIA Tree control is present #3023
Comments
Attachment technical_style_guide.zip added by bgaraventa on 2013-02-22 19:57 |
Comment 1 by jteh on 2013-02-24 03:07 |
Comment 3 by James Teh <jamie@... on 2013-05-08 07:15
|
Comment 4 by James Teh <jamie@... on 2013-05-08 10:09
Changes:
|
Comment 5 by bgaraventa on 2013-10-10 23:57 An example can be tested at 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. |
Comment 6 by mdcurran on 2013-10-11 05:04 |
Comment 7 by jteh on 2013-10-11 06:28 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. |
Comment 8 by bgaraventa on 2013-10-13 00:40 As referenced above: 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 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 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 Please read the ARIA spec at 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 |
Comment 13 by bgaraventa on 2013-10-14 20:23 One of the things that confused me was 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 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. |
Reported by bgaraventa on 2013-02-22 19:54
Properly marked up ARIA Tree controls do work properly in NVDA in both IE 8 and 9 and in FF when you tab to the field, which then enters Applications Mode. You can then use the arrow keys to navigate the tree structure to expand and collapse branches and brows leaf nodes.
However, if you are navigating the page using the arrow keys, such as starting at the top, then moving to the bottom using only the Down arrow key, the nature of the ARIA Tree is not conveyed, and all of the tree nodes are visible, which is confusing because it doesn't look like an actionable form control.
It would make more sense if the field, when arrowing, was conveyed as one item, like a Select form field, where the explicit label of the field via aria-label was announced, and the first selected node in the tree was also announced, followed by the keyword "Tree" or "TreeView".
This would make it obvious to those arrowing down the page, that the ARIA Tree was one form field, with one tab stop, and that it is necessary to enter Applications Mode in order to interact with the control more fully.
I've attached a sample of this, which is part of a traning course I'm building for Cal State. The practical is contained within the folder: Coding Arena\ARIA Trees\Tree (External XML)
The same behavior can be observed in both IE and FF.
The text was updated successfully, but these errors were encountered: