Select with aria-label
generates invalid aria-labelled-by
attribute for options list
#6123
Closed
1 of 2 tasks
Labels
Fixed patch
Completed issues that will be published with next patch (1.0.X)
Dependencies check up
What version of @mantine/* packages do you have in package.json?
7.8.1
What package has an issue?
@mantine/core
What framework do you use?
Next.js
In which browsers you can reproduce the issue?
All
Describe the bug
When using a
Select
component labelled with anaria-label
, rather than visiblelabel
, the options listbox is still rendered with anaria-labelled-by
attribute that references the non-existent<label>
element, causing the listbox to be unlabelled in accessibility contexts.e.g.
Produces mark-up:
Here, there is no element with ID
mantine-mock1007-label
.(Note on the above: I've stripped out
style
attributes for legibility, and our test framework mocks @mantine/hooks#randomId to produce stable IDs, hence all themantine-mock100…
names above where you'd normally see alphanumeric codes.)Thanks!
If possible, include a link to a codesandbox with a minimal reproduction
No response
Possible fix
In cases where the Select has no
label
prop but has anaria-label
, the listbox should have its ownaria-label
rather thanlabelled-by
.While it would also be an option to have the
listbox
reference theSelect-input
(e.g.aria-labelledby="mantine-mock1007
in the above), Mozilla's docs point out that<input>
elements functioning as a label will also include the current value of the input as part of that label. That would mean if I had a Select labelled “Pick a Number” with options1, 2, 3
, the listbox would have an announced label of “Pick a number, 2”, when a value was picked. That's probably confusing for the list. Therefore, just having its ownaria-label="Pick a Number”
would be more straightforward.Self-service
The text was updated successfully, but these errors were encountered: