Component behaves differently to native <select>, causing accessibility issues

[matteason]

Ideally custom select components should behave as closely as possible to a native <select> to allow users of assistive technology to interact with them in the way they're used to. There are some differences between this component and a native select that are likely to cause accessibility issues, for example:

• The label exposed via aria-label isn't the same as the visual label above the input. The visual label should be duplicated in aria-label and the placeholder should probably be in aria-description
• The dropdown expands automatically if you use the tab key to navigate to it. A native select would only expand on certain keyboard events (see the WAI example below)
• Previous dropdowns stay open when using the tab key to navigate to the next one:
• The options dropdown itself is focusable. Focus should remain on the parent.
• Navigating the results list with arrow keys and a screen reader results in the screen reader reading 'blank' for each option, meaning the user won't know what they're selecting

There's a good coded up example of a custom editable selector at https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/. If you'd like to test the component with a screen reader, NVDA is free and widely used

[TotomInc]

Hey @matteason, thanks a lot for opening this issue, really appreciate it!

I am indeed a novice at accessibility, I will take a look at these issues.

[TotomInc]

Accessibility improvements have been published under v0.0.1-beta.3, feel free to reopen this issue (or create another one) if something is still wrong!