Lighthouse report and accessibility

[fabswt]

Description

Running a Lighthouse report for mobile on the playground (opened in a new window) returns this warning about a missing accessible name:

Getting the same on my own site running Autocomplete version 1.6.2.

Running a simple document.getElementById('autocomplete-0-label') confirms that there is no such element. (Meanwhile document.getElementsByClassName('aa-Autocomplete')[0] shows the autocomplete element to, indeed, exist with attribute aria-labelledby="autocomplete-0-label".)

Please note:

• Said label is missing on the empty state on mobile.
• It's fine after loading some data (performing a search) on mobile.
• It's fine on desktop.

Reproduction

Go to the playground and run Lighthouse for mobile.

Expected behavior

Would expect:

• the label to exist any time '.aa-Autocomplete' exists.
• the warning from Lighthouse to be gone.

Environment

• OS: macOS
• Browser: Brave Version 1.38.109 Chromium: 101.0.4951.41 (Official Build) (arm64)
• Autocomplete version: 1.6.2

Added bonus...

...the joy and satisfaction of knowing you'll help me reach a score of 100 on Accessibility 😁

[Haroenv]

Here's the relevant part of the code:

autocomplete/packages/autocomplete-js/src/createAutocompleteDom.ts

Line 83 in 24cf9d6

children: [submitButton],

It seems that the label actually exists, but only has a button inside it, and not a more relevant label like "search" (can be visually hidden of course). It seems like the button should be a sibling rather than a child of the label, but I don't know if fixing that would be a breaking change

[sarahdayan]

In detached mode, the label only exists when the search modal is open. When it isn't, there's only the search button in the DOM which wrapper has the role="combobox" and aria-labelledby="autocomplete-0-label". But because the label is in the modal (which is absent from the DOM), Lighthouse legitimately reports an accessibility issue.

One simple solution would be to add a <label> near the search button (visually hidden) when the modal is closed, and remove is when it opens so that the combobox is now labelled by the one in the modal.

Another option would be to reconsider having the role="combobox" around the search button in detached mode. I gather that the goal may have been to express that an unexpanded combobox is in the page, but although we could fix the Lighthouse, it may not be an optimal solution for someone actually relying on a screenreader.