Possibility of using right arrow to reach a secondary action/ context menu on tree items

[mbgower]

A team is interested in having a context/overflow menu in a tree, to allow the addition of new folders, deletions, renaming, etc.

Since context menu is not something easily invoked on a mac keyboard, they have been exploring using right arrow to provide access to an overflow menu inside a tree node.

For end nodes, this would seem to be conflict-free, since right arrowing on an end node has no current action.
For a parent node, right arrow has an action. However, right arrow on an open parent node has an action which I would call a redundant action. All it does is move to the first child node of the parent, which can also be accomplished with a down arrow.

I'd like to find out reactions to the model this team is proposing. Currently, the guidance in the APG reads:

Right arrow:
When focus is on a closed node, opens the node; focus does not move.
When focus is on a open node, moves focus to the first child node.
When focus is on an end node, does nothing.

The interaction with their variant would be something like:

Right arrow:
When focus is on a closed node, opens the node; focus does not move.
When focus is on a open node, moves focus to the first child.
When focus is on an end node, moves focus to child, if one exists.

This is somewhat connected to discussions like w3c/aria#1120

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3217 - Proposal for accessing context menu in trees.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3217 - Proposal for accessing context menu in trees
<jugglinmike> github: https://github.com//issues/3217
<jugglinmike> Matt_King: Right now, normally, to get to context menus with the keyboard, you would have to press shift+f10, but on Macs--I actually don't know how to do it on Macs if you're not a VoiceOver user.
<jugglinmike> Matt_King: There might not even be a way to get to context menus with the keyboard if you're not a VoiceOver user
<jugglinmike> Matt_King: To require shift+f10 on a Mac creates an unusual discovery problem
<jugglinmike> Matt_King: But if there's an icon that's to the right of the tree node, then perhaps you could use the right arrow
<jugglinmike> Matt_King: Is the icon traditionally on the right? It would be very strange if it was on the left and you pressed the "right" arrow to access it!
<jugglinmike> Matt_King: I'm looking at a Windows one. It makes sense that, on an open parent node, the right arrow would move to the first child. But it is, as they point out, redundant because as soon as you press right-arrow again, it doesn't go to the next sibling; it goes nowhere. You have to switch to using down-arrow
<jugglinmike> Matt_King: It is a little interesting that in order to get to the context menu for a parent node, you would have to first expand it, and then you would be able to get to the context menu. Which I guess is fine as long as expanding doesn't have any side-effects...
<jugglinmike> Matt_King: But I guess that's more of an "app design" issue
<Jem> https://github.com/w3c/aria/issues/2300
<jugglinmike> Jem: The ARIA spec does not provide information about the way to determine how many items caused the menu to open.
<jugglinmike> Jem: Is there something here that we can resolve within ARIA instead of within our practice pages?
<jugglinmike> Matt_King: Well, I think this actually--this present proposal is not about the structure of the nodes or the DOM. It's about the keyboard interaction specifically
<jugglinmike> Matt_King: The way that they have worded the proposal, though, it sounds like they are thinking that the context menu button would be a child, I guess of the tree item.
<jugglinmike> Matt_King: The way it's written in the proposal, though, it seems like it would have to be more clear
<jugglinmike> Matt_King: I don't think there's any down side to this idea (that I can see)...
<jugglinmike> Matt_King: So, we had talked about making another ARIA-Actions example using tree. At one time, Adam_Page had suggested that he might be open to working on that
<jugglinmike> Adam_Page: Yes, I think I did, and I think I would still be. I'm working on a separate thing which came up last week (Scott's expandable region)
<jugglinmike> Matt_King: Oh, right
<jugglinmike> Matt_King: One question I had is: in the case of a tree, would it be fairly common for there to not just be one button for context sections, but for there to be a whole collection or row of buttons (separate buttons for, say, "delete" or "move up" or "move down" or "rename")?
<jugglinmike> Jem: One design I observed was state medicare app. They were struggling with the design--that you could remove one line and at the same time add a line and edit it. One line had different options
<jugglinmike> Matt_King: Lately, I've seen more resistance to adding a menu button which people have to click to learn what the actions are. Designers seem to be preferring to display all the available actions so they can be readily reviewed
<jugglinmike> Matt_King: What should our feedback here?
<jugglinmike> Matt_King: Does anyone see any reason they shouldn't be using the right arrow to explore additional actions?
<jugglinmike> Jem: Can you explain "node"?
<jugglinmike> Matt_King: A node is a tree item. You have root nodes, parent nodes, and end nodes... But they're all just tree items
<jugglinmike> Matt_King: Think of an "<li>" with "role=tree" on it. That could have, inside of it, the name of the tree item as well as several buttons. Those buttons might only be shown visually when there's hover or focus on that item
<jugglinmike> Jem: What is the relationship between one item with different options? I know it might hold it as context, but there's no "owned" or "parent"...?
<jugglinmike> Matt_King: The relationship would be "aria-actions". The "<li>" would have aria-actions
<jugglinmike> Jem: Ah, right, that's why we came up with aria-actions
<jugglinmike> Jem: Do we ask Mike to come up with a draft?
<jugglinmike> Matt_King: He did include some potential revisions to the arrow key language in this issue. The thing that I would suggest to change is that I don't know if we would want to use the term "child item" because it could be misconstrued as as another tree item
<jugglinmike> Matt_King: I think that by "first child", he means "child that represents the context action"
<jugglinmike> Matt_King: The use of the word "child" in the description is a little problematic because I'm not sure what "child" represents
<jugglinmike> Jem: Can we use the aria-action concept here?
<jugglinmike> Matt_King: Yeah, I think that's what the intent is
<jugglinmike> Matt_King: I can write a comment to ask for some additional clarity
<jugglinmike> Zakim, end the meeting

[mcking65]

@mbgower wrote:

The interaction with their variant would be something like:

Right arrow:
When focus is on a closed node, opens the node; focus does not move.
When focus is on a open node, moves focus to the first child.
When focus is on an end node, moves focus to child, if one exists.

Mike, in this variant, does child mean child element inside of the tree item, e.g., does the term "child" refer to "action1" and "action2" in the following:

<li role="treeitem" aria-actions="a1 a2">
  foo<button id="a1">action1</button><button id="a2">action2</button>
</li>

[mbgower]

Mike, in this variant, does child mean child element inside of the tree item
@mcking65 I would say yes.

I'd been thinking of it as a single button which would invoke an overflow menu, but otherwise similar.

[mcking65]

Mike, in this variant, does child mean child element inside of the tree item
I would say yes.

I'd been thinking of it as a single button which would invoke an overflow menu, but otherwise similar.

OK then, with that in mind, we need to consider some other wording for the description of left and right arrow interactions. The language you suggested equates children of the treeitem with groups containing child nodes of the tree. The pattern also needs to consider the multiple non-group child use case suggested by the code snippet in my prior comment.

[mbgower]

I guess one could also potentially implement this as a tree grid, but that seems like overkill for the use case.