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. 🤔

Explore Other Notes

  • A great overview of why a custom select component can be [&#8230;]
  • Murray Adcock.
Journal permalink

Made By Me, But Made Possible By:


Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.