I thought it's a same drill, but it looks like there's a known aria gotcha with tree view pattern. Not sure how much we need to fully align, but leaving a full context here.
Motivation
The explorer currently requires clicking each test, suite, or file to inspect it. This makes quickly skimming test results cumbersome, especially when moving through several neighboring entries.
Trace steps recently gained keyboard navigation for the same workflow. The explorer could similarly let users keep focus in the tree and browse details without repeatedly moving to the pointer.
Keyboard support would also make the explorer behave as an accessible tree rather than a list of pointer-only rows.
Proposed Behavior
The keyboard model follows the W3C WAI-ARIA Tree View Pattern. When an explorer row has focus:
- ArrowUp and ArrowDown move to the previous or next visible row.
- Home and End move to the first or last visible row.
- Moving focus with those keys selects and opens the destination, allowing details to update while skimming.
- ArrowRight expands a collapsed file or suite. If it is already expanded, ArrowRight moves to its first visible child.
- ArrowLeft collapses an expanded file or suite. Otherwise, ArrowLeft moves to its visible parent.
- Enter performs the focused row's existing default action, as specified by the tree pattern.
- Space does not introduce a separate action because the APG assigns Space to selection in multi-select trees, while the explorer is a single-select tree where selection follows focus.
Only visible entries participate in navigation, so collapsed or filtered-out entries are skipped. Reaching the first or last entry should keep focus at that boundary.
Accessibility
The explorer should implement the WAI-ARIA Tree View roles, states, and properties:
- The explorer container uses
role="tree" and has an accessible label.
- Every row uses
role="treeitem".
- Parent rows expose
aria-expanded; leaf rows omit it.
- The selected row exposes
aria-selected="true", with at most one selected row.
- A roving
tabindex gives the composite tree one tab stop while arrow keys move focus between rows.
- Because virtualization means the complete tree is not present in the DOM, rows explicitly expose
aria-level, aria-posinset, and aria-setsize.
The APG explicitly permits selection to follow focus in a single-select tree. The explorer adopts that optional model because its primary action is browsing one item's details, so updating details during ArrowUp/ArrowDown navigation directly serves the quick-skimming use case. This is a deliberate product choice rather than an accessibility requirement.
Disclosure and row action buttons should retain their existing independent behavior.
Implementation Consideration
The explorer uses a virtual scroller, so an off-screen destination may not exist in the DOM. Keyboard navigation needs to reveal such a row before focusing it, without repositioning rows that are already rendered.
I thought it's a same drill, but it looks like there's a known aria gotcha with tree view pattern. Not sure how much we need to fully align, but leaving a full context here.
Motivation
The explorer currently requires clicking each test, suite, or file to inspect it. This makes quickly skimming test results cumbersome, especially when moving through several neighboring entries.
Trace steps recently gained keyboard navigation for the same workflow. The explorer could similarly let users keep focus in the tree and browse details without repeatedly moving to the pointer.
Keyboard support would also make the explorer behave as an accessible tree rather than a list of pointer-only rows.
Proposed Behavior
The keyboard model follows the W3C WAI-ARIA Tree View Pattern. When an explorer row has focus:
Only visible entries participate in navigation, so collapsed or filtered-out entries are skipped. Reaching the first or last entry should keep focus at that boundary.
Accessibility
The explorer should implement the WAI-ARIA Tree View roles, states, and properties:
role="tree"and has an accessible label.role="treeitem".aria-expanded; leaf rows omit it.aria-selected="true", with at most one selected row.tabindexgives the composite tree one tab stop while arrow keys move focus between rows.aria-level,aria-posinset, andaria-setsize.The APG explicitly permits selection to follow focus in a single-select tree. The explorer adopts that optional model because its primary action is browsing one item's details, so updating details during ArrowUp/ArrowDown navigation directly serves the quick-skimming use case. This is a deliberate product choice rather than an accessibility requirement.
Disclosure and row action buttons should retain their existing independent behavior.
Implementation Consideration
The explorer uses a virtual scroller, so an off-screen destination may not exist in the DOM. Keyboard navigation needs to reveal such a row before focusing it, without repositioning rows that are already rendered.