Select a11y + rework

[StommePoes]

The select components have several accessibility issues. I thought it was easier to lump them all together for the single component rather than separate issues for each.

I threw together a test page https://stommepoes.nl/work/shoelace/shoelace_demo.html and, on Windows only, ran 2 screen readers (NVDA latest, JAWS 2019) on 3 browsers (Edge latest, Chrome latest, Firefox latest... as of 23 September 2020). I don't own any iThings or I would have run VoiceOver on Safari (this is the combination for MacOS that is preferred for testing) as well.

• The select component does not expose a role to assistive technologies (such as screen readers). On Windows it should call itself a "combobox". On Macs, a "popup button". It currently just offers that users can edit it, which does not let users who cannot see that it is a select (the chevron) know to open using Enter or Alt+DownArrow (plus whatever they use on Macs. I don't have one to test). JAWS seems to think they are "frames" (not sure where it's getting that from).
• In Windows screen readers at least, if users open the dropdown, no "expanded" (or collapsed) state is announced, nor are the options as users Arrow through them. Only once something has been selected and users refocus on the element is the (new) current value read out. Each <option> should expose its value as users move between them.
• The select elements have a readonly attribute (the tested component examples were the select with label example from the "select" documentation page, and the select in the "form" example).
• In the documentation, the example with the label is near the bottom. Since developers copy and paste code, it would be more ideal to only offer examples with a label, since all controls must have an accessible name.

All controls should offer a name, role and state and/or value (depending on the component).

Other than removing the readonly attribute that appears from somewhere and having the documentation ideally only offer examples of the select with a label, I don't know web components well enough to make recommendations for the other stuff. Since the roles of selects differ across operating systems, I'm not certain a role should be manually added, or if instead it is possible to have a <select> "under the hood" where the <input> is. If that's possible, then the correct role (as well as the expanded/collapsed states) would likely expose themselves for you automatically.

Note, issue #215 is also applicable.

[claviska]

Thanks again. I think some of the oddities with <sl-select> are coming from the "clever" composition of a readonly input to display the selected value (they use the same styles, so it made sense to try to reuse instead of duplicate).

I'm slating this one for a rework. The input styles can probably be abstracted so input, textarea, and select can reuse them without having to use an actual input under the hood (which will prevent virtual keyboards from showing up). It may also make sense to use the internal Popover utility directly instead of trying to compose it with <sl-dropdown>.