Open carmacleod opened 4 years ago
Are non-interactive trees in scope for the deep dive? (I have had good success with ARIA tree markup for tree-like diagrammatic content.)
Are non-interactive trees in scope for the deep dive? (I have had good success with ARIA tree markup for tree-like diagrammatic content.)
That's good to know, but I think I'd like to keep the scope of this to interactive trees for now. Thanks!
I think I'd like to keep the scope of this to interactive trees for now.
Thanks for clarifying, @carmacleod!
I edited the original to add a minor note to the Mac tree vs table comment.
For a more concrete idea of where these questions are coming from, here are the relevant links for the experimental Carbon TreeView:
Added following notes in the top comment:
After question1: 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.
After question 2: Note: using aria-current to convey active item would be appropriate per definition of aria-current.
After question 4: 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.
After question 5: Note: JAWS and NVDA do not render a full tree in reading mode. This is by design; same is true with listboxes.
Another important consideration is how to distinguish between item selection, performing the default action or expanding a tree item using a mobile screen reader. For this to work, it seems that the treeitem element should support interactive children, like a checkbox or toggle buuton in addition to a group of descendant treeitem elements.
aria-current
):General consensus was that yes, it is valid to decouple "active" tree item from "selection" from "focus", and yes, it would be useful to know which node is currently active when navigating through the tree, and aria-current = "true" is a good, semantic way to denote the "active" node.
Example is an email program. The user can have the Inbox folder "active" (i.e. showing in the panel on the right), and multiple folders "selected" (i.e. in order to do some multi-select action on them, like maybe move them into another folder), and they can still move the focus down to yet another folder (i.e. maybe intending to add that to the selection or something).
New question (also added to opening comment):
2a. 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)?
Note: Transcript for this part of the call is in the disclosure at the end of this comment.
Here are what I believe are the consensus points:
follow platform conventions for space and enter
selected and checked do have different semantics:
as such, it is "ok" (i.e. not forbidden) to use both aria-selected and aria-checked in the same tree, except that you need to consider these points:
Other notes:
Per September 3 Deep Dive on Trees discussion, here is a link to a page that contains CSS style examples of various tree design patterns we are trying to support in our design language: https://opensource.adobe.com/spectrum-css/treeview.html. Note that some of the examples, like the Thumbnail pattern, might be better suited to the TreeGrid design pattern, and that the examples are not fully functional implementations of the WAI-ARIA Tree design pattern; they're only meant to demonstrate the various CSS styles.
Here is another example, from the open source Coral-Spectrum javascript framework, that implements a multi-selectable tree with some disabled nodes using WAI-ARIA. Note that this implementation uses aria-live
and additional screen-reader only text to announce the selected/not selected state of tree items when item selection is toggled. In this implementation, Space selects the focused item and Enter or ArrowRight/ArrowLeft will toggle the expanded or collapsed state.
Deep Dive 10-minute homework. :)
Please try out the experimental Carbon multiselect TreeView. I'll paste the link below, but please read the notes first.
aria-current="true"
. Authors using this component will typically open the active item in an associated editor or viewer pane. To "activate" an item, use click, space or enter.Modulo not being able to do contiguous selection (yet), please let me know if you find this tree easy to use. We can discuss this selection model during the deep dive call.
Here's the link to the experimental Carbon multiselect TreeView.
Thanks, everyone.
@carmacleod
NVDA seems to be the only screen reader that announces selection state (i.e. "not selected") in a tree. JAWS and VoiceOver don't mention selection. That seems buggy.
The reason for this could be in VoiceOver the lack of aria-multiselectable=true on the role=tree. VO then does not output the status because it assumes that focus and selected are identical. In JAWS this is bug since it occurs also with aria-multiselectable=true: see https://github.com/FreedomScientific/VFO-standards-support/issues/432#issuecomment-686385093
@carmacleod In the carbon example, the deactivated treeitems do not get the focus and are also not perceptible with the virtual cursor. This can be ok, but also problematic if deactivated treeitems transmit information (e.g. that these treeitems exist or have a certain status like selected). See https://www.w3.org/TR/wai-aria-practices-1.2/#kbd_disabled_controls:
For the following composite widget elements, keep them focusable when disabled: ... Tree items in a Tree View
For the mobile use case, with VoiceOver for iOS, there is no way to expand/collapse or multiselect items, because there is no toggle button to expand/collapse and no checkbox to indicate selection for VoiceOver to focus.
@JAWS-test
The reason for this could be in VoiceOver the lack of aria-multiselectable=true on the role=tree.
Oh - of course! Thank-you! I thought for sure I had checked that when I first tested this weeks ago. I guess I was in too much of a hurry last night. I even had the thought that it's as if VO thinks the tree is single-select! I'll see if I can get that fix in this morning.
For the following composite widget elements, keep them focusable when disabled: ... Tree items in a Tree View
Thank-you again! I don't think I ever noticed that section of the APG. We will make those focusable. I did notice the weird behavior (mentioned in point 5 of the opening comment) but I figured it had something to do with @mcking65's response:
JAWS and NVDA do not render a full tree in reading mode. This is by design; same is true with listboxes.
@majornista
For the mobile use case, with VoiceOver for iOS, there is no way to expand/collapse or multiselect items, because there is no toggle button to expand/collapse and no checkbox to indicate selection for VoiceOver to focus.
I will admit to having no experience developing for mobile. Would people typically implement a different component on mobile? One that has separately-checkable checkboxes and separately-tappable twisties? Would that have to be a treegrid? I see that you linked to some examples in https://github.com/w3c/aria/issues/1311#issuecomment-686660535 - I will try to look through them before the call.
Sincere thanks to both of you for your feedback. I wasn't trying to get free debugging (was only trying to have discussion points for the call), but I'm grateful for it. If we ever meet at a conference (when this pandemic is over), I owe you both a drink. :)
The fix for aria-multiselectable is in (heh, my first-ever Carbon code contribution 😄 ), but sadly, VoiceOver still doesn't announce aria-selected state. On the plus side, JAWS does announce "selected" in Firefox now (but not in Chrome).
Here is the raw transcript from the previous call (very sorry - I am out of time to clean it up).
@majornista The Coral Spectrum tree seems nice. The screen-reader only text does make NVDA say "not selected not selected" when navigating through items, and JAWS double-speaks when an item is selected/deselected. (we need to get those screen readers fixed so that people don't have to do hacks like this to work-around screen reader bugs...)
Interesting that mouse click has the same "one at a time" behavior as space key. Do mouse users like that, or do they miss being able to select multiple items at once? I guess this works on mobile? I understand how selection/deselection would work with single-tap, but I can't see a toggle button for expand/collapse?
Regrets on the call, but we’ll make sure to submit some comments, either from myself or @jscholes on the treeview to help move this conversation forward. Also, quick thanks to @carmacleod for building this demo!
@carmacleod From the notes:
To "activate" an item, use click, space or enter. ... in this tree unmodified space is used for activation.
I don't find the presence of aria-current
confusing to represent the active item in this specific example. I can see it being used in, say, an email application or Slack to indicate which folder or channel you're in, in the specific case that a user must press Enter to change the active context.
On the other hand, I do feel that it's only being introduced here to support an explicit selected state along with the need for manual activation. Arguably, if an application didn't need to support the multiselection of something, and/or the panel was automatically switched as user's navigated through a tree, selection could just follow focus. Hence we may end up with some trees which use aria-current
to mean active and some which just use selected state for the same thing. aria-current
wouldn't work with automatic activation, because a screen reader would say "current" before or after every item and it would become semantically meaningless.
How will users respond to differing indications of active item state across tree implementations? Arguably, the lack of explicit "selected" announcement by NVDA and JAWS on Windows has trained users to infer selected state in many cases. If there was a case of a tree where the active item was further down and used aria-current
, but the first item was automatically preselected for some reason, would users incorrectly assume that the first item was the active one?
In addition to the above, when I load this page, the first item "Artificial intelligence" is reported by NVDA as being "not selected". My immediate thought is to press Space on it to select it, because that's ingrained in me from years of Windows experience. Having read the notes beforehand, I believe that Space should only activate the item and mark it as "current", but leave its selected state unmodified. But then something confusing happens:
Maybe I'm misunderstanding how the example should work... some clarity would be appreciated here.
Some misc. technical observations:
As per discussion elsewhere, would there be interest in a deep dive call about trees and mobile / touch?
Hey @smhigley James and I thought you might be interested in some of these points, as you are thinking about checked vs selected and interactive lists, etc
The next Deep Dive on Trees will be on Thurs Sept 3.
Questions:
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.
Note: using aria-current to convey active item would be appropriate per definition of aria-current.
a. Just to confirm, if we have an "active" tree item (i.e. with
aria-current="true"
), should we be usingaria-controls
to point from the tree to the "active" region (i.e. side panel)?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 #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.
Checkboxes. After discussing #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.
Note: JAWS and NVDA do not render a full tree in reading mode. This is by design; same is true with listboxes.
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?