Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interaction pattern for secondary actions on interactive widgets #1407

Closed
smhigley opened this issue May 18, 2020 · 2 comments
Closed

Interaction pattern for secondary actions on interactive widgets #1407

smhigley opened this issue May 18, 2020 · 2 comments
Labels
enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force

Comments

@smhigley
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

mcking65 commented May 6, 2024

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

@mcking65 mcking65 closed this as completed May 6, 2024
@mcking65 mcking65 added enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force labels Jul 27, 2024
@mcking65 mcking65 added this to the H1/2024 APG Improvements milestone Jul 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Any addition or improvement that doesn't fix a code bug or prose inaccuracy Feedback Issue raised by or for collecting input from people outside APG task force
Projects
None yet
Development

No branches or pull requests

3 participants