-
Notifications
You must be signed in to change notification settings - Fork 78
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
Unexpected keyboard navigation experience with nested trees #6861
Comments
Per our Teams discussion, adding the |
@geospatialem Added more to reproduction steps |
Thanks @SaraLawrence! Reorganized content a bit in the above description. Updates will be posted on next steps once triaged. |
Research will be conducted in an upcoming milestone prior to assigning to developers. |
Anticipated keyboard behavior (with and without AT active):
|
Reallocating the target to the August milestone for the development effort. |
**Related Issue:** #6861 ## Summary Improves tree's keyboard navigation to move across all items and users can now tab to the next focusable element without having to traverse all items. ### Notes * items are now programmatically-focusable only (e.g., `tabindex="-1"`) since the tree moves focus * keyboard navigation based on https://www.w3.org/WAI/ARIA/apg/patterns/treeview/examples/treeview-1a/#kbd_label * consolidated tree tests and improved coverage * moved all navigation logic to the tree-level * refactored item traversal logic to cover all cases * moved tree `keyDownHandler` to use VDOM event.
Installed and assigned for verification. |
Verified in |
Summary
Questioning the use of nested trees and the effect on keyboard only users. Also, wondering why slots are implemented at the tree-item level rather than at the tree level?
Actual Behavior
Keyboard only users expect to be able to navigate between nodes with the up and down arrow keys and also move into a group of children using the down arrow. It is confusing to have to first press right or left arrow in order to move up or down.
Also, screen reader support for trees is not consistent and implementing them as a series of trees when visually they appear to be one component, can be confusing for blind screen reader users.
Example: JAWS only recognizes two of the four patterns in the sample codepen:
Expected Behavior
tab
is to move into the tree and out of the tree. With Calcite,tab
moves to what visually appears to be the next "depth 1" item. This is confusing for screen reader users because they can't see the relationship that appears visually between "Grandfather" and "Great uncle".role="tree"
, and the commands should follow the pattern, with down-arrow and up-arrow always available.All of the W3C and Deque examples use
role="group"
to contain child items, rather than nesting trees and the keyboard behavior is more straightforward.Reproduction Sample
https://codepen.io/paulcp/pen/GRYjaoY
Reproduction Steps
Reproduction Version
1.2.0
Working W3C Example/Tutorial
See Expected Behavior
Relevant Info
Windows 10, Chrome, JAWS, NVDA
Regression?
No response
Priority impact
p3 - want for upcoming milestone
Esri team
ArcGIS Online
The text was updated successfully, but these errors were encountered: