I've been working on an accessible custom select component for the last few weeks. By far one of the most difficult components I've ever built. Getting all the tiny interactions right, and emulating native behavior across platforms is so challenging!

Thread...

Everything is implemented according to the collapsible listbox ARIA pattern. The arrow keys can be used to open the listbox and navigate the options, along with Page Up/Page Down, Home/End. The Enter or Space keys select an option. Escape dismisses it.

https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html

Typeahead is implemented both inside the listbox and while the select is closed. This allows quickly selecting an item by text. In an address form, for example, you can tab to the state dropdown and start typing your state to select it, without opening the menu at all!

On mobile, the popover is replaced by a tray, which allows a bigger area for users to scroll.

We also ensure that users can use the next/previous buttons on the software keyboard in mobile browsers to navigate between form elements.

Native browser form autofill is supported by rendering a hidden native select and handling its onChange event.

For long lists, the listbox is virtualized, which makes sure it can be shown quickly without waiting for the browser to layout all of the items. Lots of work went in to make sure this is accessible, including focus management when an item scrolls out of view.

We worked hard to ensure that everything works well with screen readers, on both desktop and mobile. This included adding some hidden buttons at the start and end of the listbox to hide the popup, which is especially important when navigating with a touch-based screen reader.

And before you ask, yes, all of this will be open source very soon. The best part is that it's totally abstracted away from our design, so you could use it in your design system too and get most of these interactions and accessibility features for free!