Interaction pattern for secondary actions on interactive widgets

[smhigley]

There are a number of use cases that repeatedly come up for handling secondary actions on interactive elements within complex widget patterns like trees, grids, tabs. etc. For example:

• An in-browser code editor has tabs for open files, each of which has a close button
• A tree view representing a list of files has secondary action buttons to remove, or edit each tree item
• A chat app has individual chats marked up as tabs within a tab list. Each tab can be pinned, muted, or removed.

We have a description of how to handle this within a grid, though no example yet. We don't have patterns for how to accomplish this in any other complex widgets. It seems like something we should look into providing documentation and examples for, and figure out if the best interaction pattern would require any ARIA changes around allowed children.

So far, I've seen this solved (when there is any accessible solution attempted) in one of the following ways:

• A custom context menu that duplicates the secondary action buttons
• Custom keyboard shortcuts for each action
• Some sort of tab/modifier key + arrow key/enter and esc/other random workaround to get focus to the secondary actions without interfering with the default widget keyboard navigation
• Specifically for treeviews, I've seen teams use a treegrid instead, with the secondary actions in separate columns.

I think the first two (custom context menu and keyboard shortcuts) have the benefit of not requiring nested interactive elements or changes to the ARIA spec. The drawback is that they're not particularly discoverable, and work better for power users.

The third option has the benefit that it can be tailored to feel more intuitive and discoverable to less- to moderately-experienced users. The drawback is that they'd likely require spec change, and some discussion around exactly what the keyboard interaction and semantic structure should be.

Regardless of which approach is best, these have come up regularly enough that I think we should explore creating example patterns for them, perhaps starting with grid (since we have an interaction spec already written), then perhaps tree and tablist?

What does everyone else think?

[StommePoes]

Recently coming back to auditing an in-browser IDE which currently relies on more special keyboard-shortcuts than even someone without my awful memory can't possibly keep track of. They've got the closable-editor-tabs-thing where you can also rename the open file from from temp.py to yourfile.py directly in the tab... so happy to see some discussion.

[mcking65]

Closing because this is addressed by w3c/aria#1440 and #3015.