[insiders] ARIA attribute manually set on `Listbox.Button` is not rendered

[benface]

What package within Headless UI are you using?

@headlessui/react

What version of that package are you using?

0.0.0-insiders.dcbcd79

What browser are you using?

Chrome

Reproduction URL

https://codesandbox.io/p/sandbox/amazing-glitter-forked-ctqf7f?file=%2Fsrc%2FApp.tsx%3A13%2C25

Describe your issue

Notice that the aria-describedby="description" attribute on Listbox.Button is not rendered.

However, if I add as={Fragment} to Listbox.Button and put the attribute on the child <button>, then it is rendered correctly.

[adrian527]

Can recreate an issue, work on it.

[adrian527]

Solution: https://github.com/tailwindlabs/headlessui/pull/3119

[RobinMalfait]

Hey!

In this case I think the better thing to do is to use our Field and Description components instead:

<div className="App">
  <Field>
    <Description>hello world</Description>
    <Listbox value={listboxValue} onChange={setListboxValue}>
      <Listbox.Button>{listboxValue}</Listbox.Button>
      <Listbox.Options>
        <Listbox.Option value="Option 1">Option 1</Listbox.Option>
        <Listbox.Option value="Option 2">Option 2</Listbox.Option>
        <Listbox.Option value="Option 3">Option 3</Listbox.Option>
      </Listbox.Options>
    </Listbox>
  </Field>
</div>

This way you don't have to worry about managing the aria-* attributes yourself. In the future we probably will accept and prefer incoming aria-* props instead of the ones that we know about. This could lead to incorrect links between controls and labels/descriptions if you are not careful, but it would be a way to override the values we know about.

The reason it is currently not rendered on the Button is because we override it with an internal value (which is currently not defined because no Field was used, the moment you use a field it will prefer that value over the incoming value). Again, I think we will accept and prefer aria-* props in the future if there is a need for this.

Going to close this for now, but let me know if you really want to use custom aria-* props instead 👍

[benface]

Thank you for the thoughtful response @RobinMalfait. The solution doesn't quite work for my use case, but that's OK because it works with as={Fragment} (is that expected, BTW?)

In the future we probably will accept and prefer incoming aria-* props instead of the ones that we know about. This could lead to incorrect links between controls and labels/descriptions if you are not careful, but it would be a way to override the values we know about.

Should this issue be re-opened as a feature request, then? 😁