…it is now thoroughly clear that recreating the native behavior of a <select> element is impossible: its underlying semantics differ across platforms; its keyboard behavior is inconsistent; its mobile presentation and behavior is entirely different from desktop. In making a custom UI control, we take upon ourselves what was the browser’s responsibility to define semantics, presentation, and behavior, and this means we must choose one single implementation to serve to everyone.
— Sarah Higley, Web Developer at Microsoft
Even Angular Material documentation says “The native <select> offers the best accessibility because it is supported directly by screen-readers.”
Angular Material also supports use of the native <select> element inside of <mat-form-field>. The native control has several performance, accessibility, and usability advantages.
Before you attempt to use one of these, be certain a native <select> is not an option and you understand the commitment for coding and testing across all platforms.
Code examples
Use the Semantic HTML <select>
This native select contains all the accessibility criteria for free and is styled to look cool.
This select is focusable with all options disabled.
By using aria-disabled="true" and disabling each option, the select is more discoverable for people using a screenreader.
Disabled select
This select is completely disabled and not focusable, making it harder to discover for people using a screenreader.
Select with hidden label
While it’s inadvisable to ever hide a control’s label, there are times when because of the context and placement, it’s kinda okay. But… really please don’t.
Article archive
Bad example
Don’t use selects for non-logically sequential information
This select would be better served as a set of radio buttons allowing inspection of all options without hiding them