Accessibility: Sort by select option names are not available to assistive technologies

[evelynhathaway]

On the uwu branch (PR #497), the "Sort by" select field cannot be operated using a screen reader as the aria-labelledby overrides the accessible name of the option and the aria-describedby provides unrelated verbosity.

To replicate, use a screen reader (I used NVDA) and trigger the sort by select field. Once you pseudo focus the non-selected options, you'll hear the entire field accessible name ("Sort by: Relevance"), the state ("not selected"), then the description of seemingly unrelated control ("Content to display[,] All[,] All articles[,] Collections", commas added to show where these names are coming from in the DOM), and lastly its position in the option list (e.g. "2 of 3"). Nowhere does it say the option "Newest", and it's hard to process this level of verbosity.

[fennifith]

Adding a possible cause for this behavior: It seems like the random IDs that react-aria generates are running into a collision, where the aria-labelledby/describedby identifiers end up pointing to the "Content to display: All/Articles/Collections" radio group on the other side of the page. In testing, I'd found that react-aria2972219041-P0-9 was used both to describe the "Oldest" option as well as the radio group aria-labelledby.

React-aria seems to be using React.useId() internally, so there might be something strange happening with the imports that causes it to reset between uses.

[evelynhathaway]

I've never personally had trouble with useId unless the component tree isn't the same between client and server (not tested, but unlikely unless there is conditional logic or an invalid DOM tree that the browser is automatically rectifying) or if there are multiple react or react-aria packages installed or in the bundle (checked, only one preact and react-aria).

I haven't used Preact and useId but i don't see any relevant issues on their side. I am curious to know where this is coming from since it's new to me!

[crutchcorn]

This is almost certainly the same Preact Astro bug that @fennifith had to work around earlier

[fennifith]

^ I thought that wouldn't be possible, since the entire search page is in a single Astro island, but it turns out you're right!

I've got a minimal repro. set up here: https://stackblitz.com/edit/github-am6ghs?file=src%2Fcomponents%2Fbase.tsx

Turns out that the popover uses createPortal which places it outside of the Astro island, and that causes useId to restart its numbering from 0 for all of the popover contents!

That said, I think we can just override all of those properties to undefined, and those conflicting IDs shouldn't affect any other components. (nothing inside the popover should need an ID, afaik)