Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Circular Color Picker: Improve HTML Semantics and Interactions #20372
The Circular Color Picker is currently marked up as grouping of
Proposal to be discussed
If this isn't possible, then we could convert this to a grouping of buttons using an
I've tried building a super simple experiment with radios:
Arrow keys work (almost) as expected and they definitely feel better than the current implementation where the arrow keys move your cursor in the editor, possibly changing focus to a different block and completely hiding the color picker. I haven't tested yet with an assistive technology but I expect radios to have a more logical structure than separate buttons.
Things I've noticed:
I don't mind either of these but we need to evaluate it in context of already having an implementation live and we need to look at it from accessibility perspective too. We can most likely code these non-standard interactions on top of radio buttons but I think we might be better sticking with the most standard way possible.
Would you think this could be a good way forward?
Thanks for putting this together, @marekhrabe!
I like the idea of using radio buttons.
I agree with you, but my guess is that most people who are not familiar with this arrow interaction are not people who generally use keyboards to interact with the inputs.
100% agree. Coding non-standard interactions feels like digging ourselves into a hole.
My biggest concern with using radio buttons is that the default radio button interaction is to move to and select the next radio button. So, if someone had a custom color set already, then cycling through the radio buttons would clear their selection. Since these don't actually look like radio buttons:
I'm going to have to think over this some more... I'm so glad you put together that little interaction and your thoughts on it. It's very, very helpful!
This is an important one, thanks for mentioning! I kinda like that cycling through the options provides you with an immediate "preview". What might be concerning is possibly creating way too much undo operations than expected. I believe each arrow key press would leave an undo operation so in order to go back to whatever you started with, you might need to trigger undo for each color selected on the way.
Creating a bunch of undo operations would happen with any radio option, though, wouldn't it? You don't need to use the arrow keys anyway unless you want to change the option, as far as I can tell. If you just want to get to the next control on the page, you would just press tab. I would assume there's no reason to use the arrow keys to navigate through radio options other than to select a new option, so if it's consistent with other radio controls I would consider that a plus.
I also think that having to tab through each option (which is the current behavior) before you can get to the next control is not good. At the very least, I think we should change this so that the arrow keys are used for switching focus between options within a color picker, and tab/shift-tab is used for moving in/out of the control as a whole.
All excellent points
I'm 100% in favor of using whatever the most semantic HTML element for this is and not rebuilding the interactions. If that's a
This issue was discussed today during the Accessibility Team's weekly meeting.
We found that the color picker component is already using a
The consensus is that the team has no strong preference over which method to use. We think Radio buttons could work, since they have a similar interaction as the current implementation.
One concern was that with the current implementation, you can press a button to disable the color (and reset to default color), but with radio buttons that’s not possible natively. The only option would be the “Clear” button or add a radio option of "default".