The next Deep Dive on Trees will be on Thurs Sept 3.

• Active, Activate: Relationship between Enter, Space, single-click, double-click, Windows, Mac
  • concept of "active" treeitem: the one whose content is "currently showing" in a corresponding/controlled viewer/editor panel/dialog, etc
  • aria-current="something"?
• Relationship between aria-selected, aria-checked, "active" treeitems in single-select and multi-select trees
• Mac/VO role=tree conveys the APG tree example as a table, with "list boxes" for treeitems. Is it using AXTable instead of AXOutline? (IIRC, this an artifact of AppKit trees being implemented as single column tables. Could file as a VO enhancement request. – jc). (ok, opened webkit 215698 - car)

Questions:

1. Spec for treeitem says aria-selected is required, spec for aria-selected says something like, "not required in single-select trees where selection follows focus because the user agent can figure that out". This is discussed in Clarify if aria-selected & aria-checked are required on roles 'treeitem' & ('menuitemcheckbox', 'menuitemradio') respectively #798 and Should aria-selected be listed as required for option role?  #700. Not sure if requiring aria-selected is somehow the reason that NVDA verbosely says "not selected" for every treeitem with aria-selected="false", and does not say "selected" for treeitems with aria-selected="true". Seems like a backwards choice (except for the one case where selection follows focus in a single-select tree... but I guess that's the most common case). JAWS doesn't announce selected (or not selected) at all when arrowing through treeitems - is this a JAWS bug?

Note there are 3 use cases: 1) single-select where selection follows focus, 2) single-select where selection does not follow focus (common where a tree controls a panel), and 3) multi-select.

2. Multi-select tree with "active" treeitem showing in corresponding panel - can't denote "active item" with aria-selected because there can be many selected items, can't use focused item because that needs to move independent of selection and active item. Would screen reader users want to know which item was showing in the related side panel?

Note: using aria-current to convey active item would be appropriate per definition of aria-current.

2. a. Just to confirm, if we have an "active" tree item (i.e. with aria-current="true"), should we be using aria-controls to point from the tree to the "active" region (i.e. side panel)?

3. Space key. APG guidance separates unmodified Space key and Enter key, using Enter to "activate" a node (i.e. perform its default behavior), and Space to aid in selection in a multi-select tree. But Space is typically used for "activation" on Mac (see Change contain to own in Required Owned Elements and Required Context Role #1438), so if a tree wants to use both Space and Enter for the default action, what would the keyboard guidance be for multiple selection? Same as the "Alternative selection model", where modifiers are always required to retain the current selection? Note that Cmd+Space is spotlight.

4. Checkboxes. After discussing aria-checked on option and treeitem #1052, we ended up saying, "it's ok to use aria-selected OR aria-checked on treeitems, but not both in the same tree", because dual-state "selected, not checked" and "not selected, checked" are hard to understand. Also, you'd need to have separate behavior for the space and enter key (one to select, one to check/uncheck), which would break users. However, there may be use cases that want to use both, such as batch operations (select a bunch of items and then delete, rename, check, etc). Perhaps the best way to do this is to allow real checkboxes in treeitems?

Note: putting a checkbox inside a tree item would not solve this. It would end up being equal to a checked tree item. Visually, it can look like a checkbox inside or adjacent, but from ARIA perspective, a checked tree item and a tree item containing a checked checkbox would end up with the same UX.

5. Disabled treeitems with aria-disabled. Not sure how disabled tree treeitems would be discovered, other than going into reading/browse mode. There's something weird about browse mode in a tree, though. I tried typing escape while part-way through the APG tree example with NVDA, and it seemed to get "stuck" - down arrow only through one branch of the tree and then refuses to keep reading.

Note: JAWS and NVDA do not render a full tree in reading mode. This is by design; same is true with listboxes.

6. The APG example expands/collapses nodes when the user clicks on either the "twistie triangle" or the parent node's text. However, in a multi-select tree where the design wants expandable (parent) nodes to be selectable, we don't want selection to happen when the mouse clicks on the text, because the user may just want to expand/collapse without losing their selection.
   Similarly, the user may just want to select a node by clicking its text, without expanding/collapsing.
   So is it ok to decouple selection from expand/collapse when using the mouse? It is already decoupled when using the keyboard, because right/left arrow expands/collapses, and "something else" selects (i.e. maybe up/down arrow, or maybe space, maybe combined with modifier keys, etc). Assuming this is ok, we would make sure that the little expand/collapse twistie triangle is at least 44 x 44 px (to pass WCAG and ensure it's large enough for users to click/tap easily).

   In a single-select tree, I've often seen double-click on the node's text which selects and expand/collapses. In those cases, single-click only selects (i.e. select and expand/collapse are partially decoupled). Would we typically recommend that on single-select trees, to give a larger click area?