Skip to content

VoiceOver doesn't always navigate Radio Button Group successfully  #7002

@phinch

Description

@phinch

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.
image

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

  1. Focus on the radio group
  2. Use VO+→ and and VO+← to move through the buttons and labels of the component
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions