Add valid labels for search button and input fields (a11y issue)

[batpigandme]

Both the collapsed and expanded search features (the button, and then the input field) currently have aria-labelledby properties set that reference an element that doesn't exist (and, thus, they have no label)

<div class="aa-Autocomplete" role="combobox" aria-expanded="false" aria-haspopup="listbox" aria-labelledby="autocomplete-0-label">
<button class="aa-DetachedSearchButton">
...
</button>
</div>

There are three associated accessibility issues I get related to the search:

1. ARIA input fields must have an accessible name
   Element: <div class="aa-Autocomplete" role="combobox" aria-expanded="false" aria-haspopup="listbox" aria-labelledby="autocomplete-0-label">
2. Buttons must have discernible text
   Element: <button class="aa-DetachedSearchButton">
3. ARIA attributes must conform to valid values
   Element: <div class="aa-Autocomplete" role="combobox" aria-expanded="false" aria-haspopup="listbox" aria-labelledby="autocomplete-0-label">
   Error: ARIA attribute element ID does not exist on the page: aria-labelledby="autocomplete-0-label"

The third presumably applies to the search input when opened on the element below:

<input class="aa-Input" aria-autocomplete="both" aria-labelledby="autocomplete-0-label" id="autocomplete-0-input" autocomplete="off" autocorrect="off" autocapitalize="off" enterkeyhint="search" spellcheck="false" placeholder="" maxlength="512" type="search">

As far as internationalization goes, it looks like the buttons have translation parameters in the Algolia docs.

Link to issue report from audit with axe: https://axe.deque.com/issues/7854d2a8-7632-43fd-98a7-ad22683ed4d5

[dragonstyle]

This is injected by our auto-complete library, so the simplest fix would be upstream- related issue:

algolia/autocomplete#963

For now, postponing and I'll work on trying to get fixed upstream.

[signekb]

Hi!
What's the status on this? I'm having the same issue with the search button.

[cderv]

Upstream issue is still opened, and iIssue here also as we didn't do any specific handling on Quarto side.

As said, this would need to be dealt upstream in the autocomplete library.

So work to be done (which is usally the status for issue still opened in this repo)

[signekb]

Ah, yeah, makes sense. Thanks for getting back to me so quickly.

[srvanderplas]

This is going to be a much bigger issue soon, as WCAG 2.2 guidelines roll out to universities and any page used in any course must be compliant under ADA. I don't have the skills to fix this, but just boosting because I'm auditing my quarto book and finding that the search and sidebar are my biggest issues at the moment.

[cderv]

This requires an upstream library fix. It does not seem it gets traction there so we may need to spend some time trying to fix this upstream ourselves... 🤔

[batpigandme]

This requires an upstream library fix.

Yeah, there are actually three related upstream issues that all apply to Quarto as well (wherever algolia search is used). In addition to the one we’ve already linked to (algolia/autocomplete#963), there’s
algolia/autocomplete#589, and algolia/autocomplete#588 (the focus trap is also a WCAG problem, it’s just not caught in an automatic a11y audit).

Algolia has some good content on accessibility (e.g. Web content accessibility guidelines (WCAG): how to make site search work for people with disabilities), so if you can find an in, you might be able to get some traction.

[cscheid]

We're still dependent on algolia to fix this, but since the library is open source, we've decided to attempt a PR there during 1.8.

[cscheid]

Closed by #12730. (We left a PR upstream, but patched our distribution locally.)