Skip to content
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

Correctly handle ARIA tree controls in browse mode when the tree isn't focusable #3573

Closed
nvaccessAuto opened this Issue Oct 11, 2013 · 7 comments

Comments

Projects
None yet
4 participants
@nvaccessAuto
Copy link

nvaccessAuto commented Oct 11, 2013

Reported by jteh on 2013-10-11 06:24
Spun off ticket: #3023 (comment).
#3023 fixed handling of ARIA tree controls in browse mode that so that just the container is rendered, not its descendants. However, this only works when the tree itself is focusable. From what I can see, the ARIA spec doesn't specifically say trees have to be focusable. This seems odd to me, but unless I can find evidence otherwise in the spec, that's what we have ot deal with.

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.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Oct 13, 2013

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.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Oct 13, 2013

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.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Oct 13, 2013

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.

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Oct 15, 2013

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.

@Adriani90

This comment has been minimized.

Copy link
Collaborator

Adriani90 commented Dec 13, 2018

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

@jcsteh

This comment has been minimized.

Copy link
Contributor

jcsteh commented Dec 13, 2018

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.

@jcsteh jcsteh self-assigned this Dec 14, 2018

@jcsteh

This comment has been minimized.

Copy link
Contributor

jcsteh commented Dec 14, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.