You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Combobox and Listbox already support multiple selection. However (what seem not to be supported yet) such components often list chosen options as navigable tags (MUI's example):
These tags are navigable, so the user may select and delete tags. As far as I know, component libraries implement this in two ways to make it accessible:
The current tag is pointed to via aria-activedescendant. This, in theory, is the more accessible approach, as parts/subcomponents of a component should not receive focus, and instead have the component's aria-activedescendant point to them. This is a problem in headlessui, as the library controls this attribute entirely.
Via focus. Every tag has a tabIndex=-1, and keyboard arrows focus tags via .focus() (this is how MUI does it, more or less). As far as I know, this is the less preferred approach from accessibility's POV. In headlessui, this is problematic, because if a tag (and not the input) is focused, then the input doesn't receive keyboard events, therefore as long as a tag is focused, the popup cannot be navigated at all. This isn't possible to customize, as headless controls keyboard navigation entirely (this can be made work with a dirty workaround by manually dispatching KeyboardEvents on the input while a tag is focused, but this feels like relying on implementation details, because you don't know which parts of the KeyboardEvent the library uses, and you cannot make it exactly the same as a real event emitted by a real input keypress).
Does headlessui support this use case in a way I cannot see? If not, would you be open to contributions?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Combobox
andListbox
already support multiple selection. However (what seem not to be supported yet) such components often list chosen options as navigable tags (MUI's example):These tags are navigable, so the user may select and delete tags. As far as I know, component libraries implement this in two ways to make it accessible:
The current tag is pointed to via
aria-activedescendant
. This, in theory, is the more accessible approach, as parts/subcomponents of a component should not receive focus, and instead have the component'saria-activedescendant
point to them. This is a problem inheadlessui
, as the library controls this attribute entirely.Via focus. Every tag has a
tabIndex=-1
, and keyboard arrows focus tags via.focus()
(this is how MUI does it, more or less). As far as I know, this is the less preferred approach from accessibility's POV. Inheadlessui
, this is problematic, because if a tag (and not the input) is focused, then the input doesn't receive keyboard events, therefore as long as a tag is focused, the popup cannot be navigated at all. This isn't possible to customize, asheadless
controls keyboard navigation entirely (this can be made work with a dirty workaround by manually dispatchingKeyboardEvent
s on the input while a tag is focused, but this feels like relying on implementation details, because you don't know which parts of theKeyboardEvent
the library uses, and you cannot make it exactly the same as a real event emitted by a real input keypress).Does headlessui support this use case in a way I cannot see? If not, would you be open to contributions?
Beta Was this translation helpful? Give feedback.
All reactions