Date picker input accessible name is not correct

[filiptammergard]

What package has an issue

@mantine/dates

Describe the bug

In versions before v6.0.20, the accessible name of <DatePickerInput> was the chosen date, e.g. "September 6, 2023". In v6.0.20, the accessible name is the label of the button. In the example below it's "Pick date".

This means that when I use a screen reader to navigate, I'll first come to the label and the screen reader announces "Pick date". Then I go to the button and the screen reader announces "Pick date" again. I can't know what the chosen date is unless I open the date picker input. This is also counter-intuitive, since the accessible name of the button should be the content of the button.

This weird situation comes from that the picker input behaves like an input field, but is a button. When a button has a label above, you'd never expect that the label would trigger the button in the same way as clicking the button. But in this case, it feels like an input field, which would get focus when clicking the label.

Introduced in #4634 that fixed #4616.

What version of @mantine/hooks page do you have in package.json?

6.0.20

If possible, please include a link to a codesandbox with the reproduced problem

https://mantine.dev/dates/date-picker-input/#usage

Do you know how to fix the issue

Yes

Are you willing to participate in fixing this issue and create a pull request with the fix

Yes

Possible fix

I'd probably make sense to revert #4634, and find another way of focusing the input when clicking the label, if that's really intended.

I know there are probably other problems with using an actual <input> for this, but if that's the behavior you're going after, it's a bit problematic to use a <button> instead.

[rtivital]

Do you if it can be fixed by setting aria-label on the button? Reverting is not really a viable option because input is not focused when the label is clicked.

[filiptammergard]

Do you if it can be fixed by setting aria-label on the button? Reverting is not really a viable option because input is not focused when the label is clicked.

It should be fixable with aria-label as long as the value of the button can be accessed which I assume. I can give it a go if you want.

[rtivital]

Sure, you are welcome to send a PR

[filiptammergard]

Why was this input changed from a semantic input to a button in v6? In terms of accessibility, it would definitely be preferable to use a semantic input if that's the behavior you are after.