Open Anastasiia-Boleiko opened 1 year ago
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.
@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.
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.
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.
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.
@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?
yeah that makes sense to support.
@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?
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?
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.
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.
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.
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
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.
Summary
Add a new
selectionMode
prop toaction-group
,action-pad
, andaction-bar
and add keyboard interactivity on changes.Actual Behavior
The current
action-group
,action-pad
, andaction-bar
components UI are already in alignment with a toolbar pattern.Expected Behavior
"single"
, and could be bold, italic, underline, strikethrough, etc. when selection mode is"multiple"
to:action-group
action-pad
action-bar
action
s. Refer to this example for an example using keyboard navigationReproduction Sample
https://codepen.io/geospatialem/pen/JjxyZZo
Reproduction Steps
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