Keyboard a11y structure - #787
Conversation
…r TreeNode component
…to reflect tree-like structure
5231ddf to
dfd0f96
Compare
|
@Dananji Testing this out locally I'm getting errors when I try to click or activate a structure node by pressing Enter: Maybe this PR needs to be updated with similar changes to those in #784? |
Yes, I re-based this after #784 was merged, so it messed this work. I work on fixing it 👍 |
|
This is working for me now and an improvement to keyboard navigation! A couple things I noticed when testing:
|
|
Thank you for taking the time to test this @cjcolvar !
I was following the Tree view pattern in W3C and according to that, when focused on end nodes (leaf nodes) the As for making all nodes being able to be collapsed/expanded; I'm sorry, I can't visualize how this is done on an end node (leaf node). Could you please clarify this? Another solution I can think for this is to catch the
Yes, the player controls activate on both Sorry, this part of the comment is not clear to me. Could you please clarify? As for auto-advance toggle, |
|
New issue for the keyboard accessibility of auto-advance toggle: #796 |
|
Thanks for clarifying! I like the idea of arrow right not doing anything for end nodes and blocking it from advancing the player 5 sec. (Forget about the idea of making all nodes expandable/collapsible. On second thought, I think it would make the UX more confusing and less efficient.) Looking at the tree view pattern, it seems like right arrow should advance to the first child just like left should go to parent. So for this manifest (https://media.dlib.indiana.edu/media_objects/zg64tm149/manifest.json), I would expect right arrow on Side 1 (when open) to go to Track 1. For your work on nested spans I think right arrow would be able to do more since more hierarchical nodes should be focusable. For the Collapse/Expand all button, I was thinking it visually looks like a collapsible section node with the icon on the right and thus should maybe behave similarly with right arrow as expand and left arrow as collapse but maybe that is too much and confusing? |
Yes, it makes sense to adapt the same keyboard navigation pattern to this button 👍 Since, it's visualized as the root of the structure I don't think it will be confusing. I'll try it out along with the other changes. |
060d360 to
c02de24
Compare
…ns, and collapse/expand all button
c02de24 to
3bbf993
Compare
cjcolvar
left a comment
There was a problem hiding this comment.
I've reviewed the code now and this is looking good! I like the recursive TreeNode component and how it DRYs up the codebase while not being too much more complex. I found a couple things when manually testing. This seems really close to merging!
cjcolvar
left a comment
There was a problem hiding this comment.
Looks great! This will be so much better than what's in MCO right now!
Related issue: #766
Design pattern selected: TreeView (https://www.w3.org/WAI/ARIA/apg/patterns/treeview/). This pattern describes implementing accessible nested tree like structures in a UI.
The examples in this pattern, use
<ul>and<li>HTML elements in a nested structure as needed to render the given information on the page.By comparing the current
StructuredNavigationcomponent implement in Ramp, I noticed we have some unnecessary groupings at each nested level. This creates a complex DOM tree, which is a bit harder to understand and debug code-wise, and confusing for assistive technologies to interpret and present in an understandable manner.Therefore, I refactored the way Ramp build the nested structures to mimic the example implementations in this design pattern. This replaces the unnecessarily complex DOM tree we were building with a much more simple nested list pattern.
With this change,
List,ListItem, andSectionHeadingsub-components (the building blocks ofStructuredNavigationcomponent) were replaced with a single sub-component calledTreeNodewhich creates each leaf node and sub tree recursively avoiding unnecessary groupings.Keyboard navigation was then implemented on top of this structure. And the way it works is as follows;
StructuredNavigationcomponent, they can useArrowDownandArrowUpkeys to select actionable structure items (links and buttons).Enterkey updates the player to the media-fragment linked for that timespan.EnterorArrowRightkey updates the player to the media associated with the section.ArrowLeftandArrowRightkeys respectively collapses and expands the collapsible structure related to that section.StructuredNavigationcomponent, pressing tab again will move the keyboard focus to the next UI portion on the page. In the case of Ramp demo site; this is theDetailstab next toStructuredNavigationcomponent.StructuredNavigationcomponent, pressingShift+Tabwill move the keyboard focus back to theStructuredNavigationcontainer, and then pressing the key combination again move the focus the previous UI portion on the page. In the case of Ramp demo site; this is theClose/Expand all sectionbutton prior to structure.