[Action Group] selection modes and updated keyboard navigation in [Action Bar/Pad] to fit toolbar pattern

[Anastasiia-Boleiko]

Summary

Add a new selection-mode prop to action-group. Support toolbar pattern on action-pad, and action-bar and add keyboard interactivity on changes.

Actual Behavior

The current action-group, action-pad, and action-bar components UI are already in alignment with a toolbar pattern.

Expected Behavior

Blocked by #10759

• Support the toolbar pattern in action-bar and action-pad where action groups have configurable selection modes
• Add selection-mode=“multiple” | “none” (default) | “single” | “single-persist” with appropriate ARIA roles to action-group
• Support keyboard interactivity and changes, which include:
  • Implement focus management so the keyboard tab sequence includes one stop for the component and arrow keys move focus among the actions. Refer to this example for an example using keyboard navigation

selection-mode use case example:

Reproduction Sample

https://codepen.io/geospatialem/pen/JjxyZZo

Reproduction Steps

1. Open the sample
2. Observe the current keyboard behavior does not support toolbar pattern use cases

Reproduction Version

1.10.0

Working W3C Example/Tutorial

https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html

Relevant Info

If it's not possible to define a child of an element with a role="toolbar", as an alternative, there could be added an additional property that will define if navigating with arrows changes the selection or not.
But, it would be nice to have proper behavior out of the box.

Regression?

No response

Priority impact

p2 - want for current milestone

Esri team

ArcGIS Urban

[geospatialem]

Additional design insight needed on future direction, either as an enhancement with existing components, or if a new component with the above functionality should be considered.

As-is the segmented-control component is behaving as-expected for a11y support, but other considerations and the use case above should be considered.

[ashetland]

@macandcheese @jcfranco Could we do something similar to Ionic's approach? https://ionicframework.com/docs/api/segment#selectonfocus

For our version, it may need to be something like select-on-focus-disabled to align with the rest of Calcite.

[macandcheese]

I think it might be better to update Action Bar or Action Group to support this toolbar pattern. IMO Segmented Control should remain as a form-based control with the current behavior.

It could be done on Action Group, like Dropdown Group. This could allow multiple types of selection in a single “toolbar” and support our usual selection mode options, to support single and multiple toolbar selections (think, paragraph alignment for single - bold, italic, underline, etc. for multiple)

The UI of Action / Action Bar / etc. align more with a toolbar too, especially with some of the discussed bg/border options.

[ashetland]

I think I agree in principle with this, but would Action Group then need some kind of visual update? I'm not sure how a user would know, when there are multiple Action Groups in an Action Bar, that some Actions are grouped for organization, but one or more of the other groups have selection modes associated with them.

[macandcheese]

Sure, I think the Action component would need an update to support the selected display either way, either by changing our default grey active or through custom styling. Action Group should also have a separating border.

Segmented Control is problematic in UI most toolbars exist in as well, due to the border, display, etc. It’s also rectangular in icon only mode which is good, but most toolbar UI call for a square when “only icon”.

Would also be valid to use multiple Bar / Pad to cover a variety of UI needs, it needn’t always be a single Bar with multiple Group.

[macandcheese]

@driskull thoughts on having Action Group having a selectionMode with the usual suspects to facilitate these toolbar use cases with mixed selection modes we are beginning to see more and more of?

[driskull]

yeah that makes sense to support.

[ashetland]

Moved design efforts to March as other design work has taken priority. We are currently exploring the pros and cons of two paths forward for this. cc @geospatialem @brittneytewks @SkyeSeitz @macandcheese

[geospatialem]

For some additional context, in the past week we've gotten feedback from a few Online teams that the above is an important issue to tackle. Once design efforts are good to go, let's consider moving some priorities post-R3 to get this to land, if possible.

[geospatialem]

For some additional context, in the past week we've gotten feedback from a few Online teams that the above is an important issue to tackle. Once design efforts are good to go, let's consider moving some priorities post-R3 to get this to land, if possible.

In addition, we should pair this effort with #10706 to pair context between modes, for instance for actions that "launch" tooltips.

[ashetland]

Updated issue description to clarify design direction and related issues.

[github-actions]

cc @geospatialem, @brittneytewks