[Action Group, Action Bar, Action Pad] Add `selectionMode` property and update keyboard navigation to fit toolbar pattern

[Anastasiia-Boleiko]

Summary

Add a new selectionMode prop to action-group, 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

• [ ] Support the toolbar pattern, similar to something where a user could change a paragraph's alignment where selection mode is "single", and could be bold, italic, underline, strikethrough, etc. when selection mode is "multiple" to:
  • action-group
  • action-pad
  • action-bar
• [ ] Support selection modes, similar to combobox
• [ ] 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

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.

[macandcheese]

@geospatialem - Can we repurpose this or instead close and open a new one, scoped to adding support for selection-mode (none/single/single-persist/multiple) to Action Group / Bar / Pad, and any keyboard interactivity changes needed as a result?

[ashetland]

There was a concern about adding selection-modes to Action Group and what that would mean story-wise. We'd end up with two components with similar selection behaviors, but different visual presentations — single-persist action group and segmented control. I agree with the overall effort to add selection modes to Action group, but are we confident we can have a clean story about the overlap?

[macandcheese]

I see Segmented Control as a pretty separate component - it has unique, form-associated intention and keyboard interaction.

We have many other components that also share similar behavior / UX via selection-mode - Chip, List, Tile, Card, Dropdown, etc., all have implication of selection.

I do think keeping Segmented Control as a standalone form-associated component, and building richer selection-mode support into Action Group aligns with our existing story well. Ultimately it will come down to documentation and demonstration of whatever patterns we choose to support.

[ashetland]

Cool cool. Think then it may make sense to close this as not planned and log a new one, but I'll let @geospatialem make the final call.

[geospatialem]

Thanks all for the great discussion, this issue has been repurposed, rather than closed, to preserve the discussions and context above in addition to the linked a11y issues closed in favor of the above. The issue will address adding a new component to action-group, action-bar, and action-pad, which would alter the keyboard interactivity to follow suit with the toolbar pattern.

[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.