Tree View: how to implement type-ahead is unclear

[wagnermaciel]

Is the type-ahead feature meant to be able to jump focus to list items that are not visible due to having a collapsed parent?

• If yes, the examples on https://www.w3.org/WAI/ARIA/apg/patterns/treeview/#examples have a bug since they do not do this. Also, the docs should state that the parent nodes of the node that receives focus should automatically be expanded to reveal the node.
• If no, the docs should be revised to state: "focus moves to the next focusable node" instead of "focus moves to the next node".

I would like to advocate for being able to jump focus to list items that are not visible as this is most likely the most intuitive experience for users. This is also IMO the more accessible option as it removes the need to expand all nodes prior to searching using type-ahead.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 2798: Question about how typeahead should work in treeviews.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 2798: Question about how typeahead should work in treeviews
<jugglinmike> github: https://github.com//issues/2798
<jugglinmike> Matt_King: The reporter believes that the description of tree view is not specific enough about scrolling in a specific situation
<jugglinmike> Matt_King: They offer a solution
<jugglinmike> Matt_King: As far as I can tell from native implementations of tree view, their suggestion would be more of a search than a typeahead.
<Jem> https://www.w3.org/WAI/ARIA/apg/patterns/treeview/examples/treeview-navigation/
<jugglinmike> Matt_King: Scrolling to things in tree view that are inside of a collapsed node seems more like a search behavior to me
<jugglinmike> Matt_King: in my mind, scrolling into collapsed content would not necessarily be great because the user may have content collapsed on purpose--as a mechanism to limit the number of potential destinations
<jugglinmike> Matt_King: Imagine trying to use "type ahead" with a huge tree view like the Windows Registry
<jugglinmike> jugglinmike: there's also the implementation concern of tree views whose "branches" are expensive to retrieve
<jugglinmike> jugglinmike: e.g. for a file system hierarchy which requires disk I/O
<jugglinmike> jugglinmike: In those situations, implementations may intentionally defer the population of collapsed items. They can't provide a general search across all the content of the tree view because they haven't retrieved (or otherwise computed) collapsed content