Select your poison | Sarah Higley

A great overview of why a custom select component can be problematic:

1. Windows and macOS both treat native equivalents differently, meaning you have different expected behaviour for screen readers and other accessibility software straight away (Android and iOS are same as macOS);
   1. And this gets even more confusing when you include <select multiple>, which is standardised across OSes but has very poor success rates in UX tests;
   2. And even-more even more confusing when you include autocomplete or filtering capabilities, which require use of an underlying combobox.
2. ARIA already has three separate patterns (one still in discussion) so even the standards are confused;
3. Different browsers (including different OS versions of the same browser) use different default keyboard configurations, and some are not "obvious" but are expected e.g. Enter should not trigger a form submission but most users may expect it to, making it hard to utilise in an accessible way (see second article as well for how confusing this can be).

In the followup article, user testing (albeit with a small sample size) showed that - to the surprise of none - the native select element is consistently the easiest to use across platforms for basic form requirements. However, <select multiple> was comfortably the worst user experience for multiselect. 🤔