-
Notifications
You must be signed in to change notification settings - Fork 1k
Description
Hi! When using VoiceOver with a radio button group, and using VoiceOver commands to navigate through the labels, we're running into some strange behavior where the focus is sometimes forced back to the first radio button. I work on an enterprise software team, and our accessibility auditors have told us that this is violating our accessibility requirements :(
Expected Behavior
When viewing a radio button group, the user should be able to scan through the radio buttons and labels by using the VoiceOver arrow key commands.
Actual Behavior
When moving through the radio button group using the VoiceOver VO+→ and VO+←, the focus occasionally jumps back to the first radio button, which takes the user off of their focused element and back to the beginning of the radio group.
I'm wondering if the root cause is this imperative focus behavior in the radio group button...it seems like this effect would fire often, since i think onFocus and onBlur are firing often as we move through the component in VO, and since valueIndex
is 0 when the first option is selected, we would satisfy the condition where (focus && !valueIndex)
and force focus back to the first radio button? But i'm not sure i'm fully understanding all the behavior there.
URL, screen shot, or Codepen exhibiting the issue
I was able to reproduce this issue on the RadioGroup example on the Grommet website The steps might be hard to communicate because it requires VoiceOver (and tbh i'm not a VO expert), so I'll also attach a video that hopefully shows the behavior.
Steps to Reproduce
- Focus on the radio group
- Use VO+→ and and VO+← to move through the buttons and labels of the component
- Occasionally, notice that the focus shifts back to the first radio button
Reproduction example
At 0:08 and again at 0:19, you can see the focus jumps back to the first radio button even though i'm scanning the second element of the radio group
(As a bonus, our accessibility auditors pointed out that ideally, we should add focusable=false aria-hidden=true
to the "checked" icon that shows up when a button is selected, so that the screenreader doesn't read out the additional "image" text when scanning through the options - but that's less critical than the forced focus issue)
Screen.Recording.2023-11-01.at.4.36.52.PM.mov
Your Environment
- Grommet version: latest
- Browser Name and version: Chrome 118.0.5993.96
- Operating System and version (desktop or mobile): Desktop
Our team was also able to reproduce this on mobile using iOS VoiceOver, but i did more extensive testing on desktop