Closed ciampo closed 1 year ago
I'm going to work on this, I'll be opening a PR soon // cc @ciampo
Bit of a brain dump...
My initial consideration was that perhaps the most appropriate semantics would be a set of radio inputs (aria-role="radio"
or otherwise), wrapped in a radiogroup
. However, the expected standard keyboard interaction for radio inputs is to select on focus, which would be different to the current behaviour.
It's quite possible that this change would not be an issue. In all likelihood most people don't use the keyboard to navigate this component, so would not be impacted. Those that do would probably understand the way radio controls work, particularly if using a screen reader which would present the appropriate semantics.
However, given that listbox
has its own interaction model, which does not require (but does recommended) selection on focus, I think it makes sense to proceed with this idea first.
Happy to hear your thoughts though, @ciampo.
Given that @ciampo will be somewhat slower to respond for the foreseeable future, I'm wondering if @afercia / @alexstine / @joedolson / @mirka might have any input.
I think radio buttons are fine for this. Just need to make it clear to users that once an option is selected, there isn't a submit button or anything to confirm the change. Maybe an aria-live
via wordpress/a11y.speak()
to let the user know the colors were updated for X?
I am assuming that this is technically about the CircularOptionPicker
component, which may or may not be used in a ColorPalette
. For example, it's also used in DuotonePicker
.
And the way that CircularOptionPicker
is designed, it doesn't necessary have to be a single-select, and options can be deselected by clicking again. The consumer has freedom over that behavior. So radio
semantics seem too restrictive to me.
@alexstine Technically, nothing is saved until the user saves their changes to the post or template, so I think that may not be necessary. And might be inaccurate, if it implied something had been saved when it hadn't. If the normal semantics of a radio selection are maintained, I think it should be fairly clear.
Sounds good. No alert needed then.
I'd already started working on a listbox
fix for this, so despite the consensus seemingly being that radio
options would probably be sufficient, I figured I'd put it up. I'll work on making a radio
version next, which should be pretty similar.
Ended up doing more work on the listbox
work for this, based on conversations around the various restraints and permutations about how the CircularOptionPicker
can be used.
Closing as fixed by #52255
What
Rewrite the Color Palette component to use the
Composite
component and to haverole="listbox"
, so that each Color Palette becomes one tab stop.Why
Tabbing through the many options in a Color Palette can be tedious, as each color represents a tab stop:
https://user-images.githubusercontent.com/1083581/135643145-fdf13848-3d5e-4d5d-b2d0-69a69540169f.mp4
The Color Palette component is a good candidate for the
listbox
role and Reakit’sComposite
. WithComposite
, users will be able to tab to the list of color options but then use the arrow keys to navigate within the list of options. This enables users navigating with the keyboard to more efficiently navigate the UI.A/C
Composite
component internallyrole="listbox"