1942390 - Create basic moz-picker-group/moz-picker elements

Status: NEW

(Toolkit :: UI Widgets, enhancement)

Description

[Mark Striemer [:mstriemer]]

We would like to create a reusable picker component. This is likely easiest to build by extending the moz-radio-group/moz-radio components. The initial component should support all of our usual input properties we get from moz-radio, but visually hide the radio button. It would be good to add a simple border and indicate the selected option with a thicker outline, the focus styles should also surround the entire clickable label. The specifics of it don't need to be exact, we will need to tweak the styling as we add more features.

https://www.figma.com/design/2b02v18AppIpsTceWac2T3/Settings-Desktop?node-id=2908-13288&m=dev

Comment 1

[Hanna Jones [:hjones]]

Attachment: quick POC for a picker that extends moz-radio-group

Back in December I put together a quick proof of concept to show that this could be built by extending moz-radio-group/moz-radio. It almost definitely doesn't meet all the requirements for this component, but I've attached the diff in case it's useful when we start investigating this again.

Comment 2

[Hanna Jones [:hjones]]

We were discussing the focus vs selected vs selected and focused styles of the picker and realized that in many cases we may not want to have the change event/action occur on focus. For example in the case of selecting a background image in New Tab it might be distracting to have the page background change as you cycle focus through the different options (same with selecting a theme for a browser profile). Worth considering whether or not this impacts our decision to use radio inputs as the base for this component.

Comment 3

[Hanna Jones [:hjones]]

A domain specific version of this element is currently being implemented as part of bug 1936665. For this task we'll likely want to migrate that element to toolkit/widgets, adding stories, tests, and updating the code as needed while not breaking existing usage in profiles. There's some more discussion in the patch connected with that bug, but a couple of issues/questions have come up related to using visually hidden radio inputs + slots:

• How do we label elements in an accessible way for screen reader announcement? If the slotted content has a label or visible text that does not necessarily get announced, and can't be associated with the radio element in the shadow DOM. Do we provide aria-labels which would involve duplicating text/creating more fluent IDs?
• Should we continue to use radio inputs or elements with role="radio" if we need to support separating focus from selection in some cases (like in the profiles)? Usually keyboard navigation for radio inputs moves focus and selection together, but for our "picker" we want this to be configurable. We should double check with a11y on whether or not this is expected/can be handled properly by screen readers.

Comment 4

[Hanna Jones [:hjones]]

Attachment: picker-poc-take-two.diff

I put together a diff to provide a POC for how picker/picker-item could work together in the profiles case. It builds on the diff from December. Leaving it here in case it's useful when we start implementing this component.