Radio controls component has accessibility issues

The radio controls component has 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 docs show a single radio control as an example of the component. While there is some logical sense in showing this, developers using this library may not realise radios cannot be used singley.
• The grouped radios example simply has several individual radio controls placed together, sharing a name attribute. However, radio controls must be within a radiogroup element (such as a <fieldset> which has this role natively, or an element with a manually-added radiogroup ARIA role).
• Since there is not an example of radio controls within a radiogroup, it is unclear (if impossible?) to assign a name to the radiogroup. For example, in a form which asks a question where each radio’s label exposes a possible option, the question is the “name” of the radiogroup. In native HTML, this is a <legend>, which must be the first child of a <fieldset>. With non-native elements, this might be an element with a unique id, and the element with the radiogroup role is named by having aria-labelledby pointing to that id.
• For reasons I could not determine, in Firefox each radio control was announced as being “1 of 1” (instead of “1 of [total]”). In Chrome, there was no announcement of placement either way. I suspect adding a radiogroup would fix this but not 100% certain.
• In Firefox only, each of the radio controls could be Tabbed to with the Tab key, instead of the entire radio group acting as a single Tab stop. ** A note about Firefox: I tested a native set of ungrouped and a native set of grouped radio controls, to see if it was the lack of grouping causing the Tab issue. In Firefox, the grouping (or lack thereof) seems to have no direct effect. Firefox seems to allow Tabbing to each radio so long as none of them are selected. Once a selection is made, the typical native keyboard behaviour occurs. Yet in the tested Shoelace version, while there appears to always be at least one pre-selected radio, even manually mouse-clicking or using Enter to select a particular control does not bring the required “1 Tab stop per radio group” behaviour on the Shoelace radios.

It is expected that

• radio controls are only ever shown in radiogroups, even in documentation.
• radiogroups can (must) be named.
• announce their position-in-set (“one of four, two of four,” etc)
• are treated as a single Tab stop, with the possible exception of in Firefox when there is no default selection.

Desktop:

• OS: Windows 10
• Browsers: Edge latest, Chrome latest, Firefox latest (as of 23 September 2020)
• Screen readers: NVDA latest, JAWS 2019

Note: Bug #215 is also applicable

[claviska]

Interestingly, Firefox + VoiceOver doesn’t read the labels but it does announce twice as many radios. This also seems like a browser bug to me, but adding aria-hidden="true" to the internal radio input seems to alleviate it without any ill effects on Chrome and Safari.

I’ll try to look into this more soon. Thanks so much for the detailed info!

[claviska]

Radios have been refactored in #833 and #847 to solve all known remaining issues. 🎉