mi6
Radio Button Group: Incorrect List Length in Screen Reader
Summary of the bug
Our Radio Button Groups don't behave fully as lists to a screenreader, and as such when a Voiceover user navigates through a list of radio buttons they hear each one identify as "1 of 1".
Try out a native radio button list example on W3Schools) with Voiceover, and as you arrow through each radio button they will report "1 of 3", "2 of 3" etc.
We think this might be a single role/thing needs adding to the ic-radio-group. See how our other grouped components do it. Also: ic-radio-option.tsx has both role and type of 'radio' - even if this is not related to the bug it's worth de-duping.
NOTE: After a bit of experimenting moving around the role=radio and role=radiogroup the issue was not solved. This might require refactoring radio-group or radio-option more thoroughly.
🪜 How to reproduce
Tell us the steps to reproduce the problem:
- Open up any Radio Button storybook
- Activate Voiceover
- Tab into the radio button list and then use up and down arrows to navigate between them
- Each radio button will identify as "1 of 1"
📸 Screenshots or code
Example of a checkbox in the middle of the list.
🖥 📱 Device
- Type: Desktop
- Device: Macbook - Voiceover
- OS version: Sonoma
- Browser version: Chrome
🧐 Expected behaviour
Expect radio buttons within a list to identify their index within it.
The solution for this ticket appears to be to remove
shadow: {
delegatesFocus: true,
},
from ic-radio-option. The shadow dom is blocking the radio options from being aware of the other radio options in VoiceOver. Making radio options a non shadow component is a breaking change as it may break people's tests etc.
Work has been completed on branch 1804-radio-button-group-incorrect-list-length-in-screen-reader.
Moving this ticket out of sprint and into the V3 milestone.
Tried some further changes to keep the ic-radio-option as a shadow component, and making use of aria-setsize and aria-posinset, but this is still not read out by Voiceover. It did work in NVDA.
The approach taken by Shoelace is to not use a native input & instead apply the roles (and any relevant aria attributes eg aria-checked, aria-disabled etc on the host.
Such changes would also be breaking changes though
Spike to see what is involved to do it and re-write how the component is rendered. May need a guidance change as the outcome
