[terra-form-select] Option group headings not read on desktop screen readers

[mmalaker]

Bug Report

Description

The option group headings in the form select examples aren't read by VoiceOver or JAWS. Works fine on mobile though.

Steps to Reproduce

1. Using VO on Safari or JAWS on Chrome, navigate to https://engineering.cerner.com/terra-ui/components/terra-form-select/form-select/select
2. set focus to the Option Groups example dropdown
3. Navigate the dropdown menu items with arrow keys and note that the menu items are read but the option headings are not.

Additional Context / Screenshots

VoiceOver on iOS reads this text correctly.

Expected Behavior

Screen readers should read the option group heading text.

[cody-dot-js]

This is an interesting problem to solve because when scrolling through the list of options we only update the aria-live region (the contents of which is what screen readers use to determine what to announce) based on the active option (the blue highlighted value).

I'm not sure if this was previously working or what prior art does. Based on the answer to that would drive how we should go about announcing the option group labels... I imagine it would be similar to how the screen reader says "list start" at the beginning of a list, only it would say "option group name, first option name", for example.

[cody-dot-js]

Looks like native select allows us to use keyboard navigation to hover over <optgroup>s, just announcing them as dimmed (makes sense).

Problem is, when voiceover is off, native select does not allow you to keyboard navigate to the <optgroup>s, it just skips over them:

We don't have a way to determine whether AT is currently being used (or not) and since we have rolled our own custom select component implementation (which doesn't delegate to the native <select>, or <option>/<optgroup>s), we can't fallback to the native behavior that AT expects.

So, it seems like we would need to allow for keyboard navigation on all menu items, inclusive of <OptGroup>s

code:

<label for="dino-select">Choose a dinosaur:</label>
<select id="dino-select">
  <optgroup label="Theropods">
    <option>Tyrannosaurus</option>
    <option>Velociraptor</option>
    <option>Deinonychus</option>
  </optgroup>
    <optgroup label="Sauropods">
    <option>Diplodocus</option>
    <option>Saltasaurus</option>
    <option>Apatosaurus</option>
  </optgroup>
</select>

[lokesh-0813]

@dev-cprice With a bit of investigation I noticed that we need to make some major changes to have keyboard navigation applicable to <OptGroup> especially in the MenuUtil.js where we flatten the objects and filter Options. Also handling both <OptGroup> and <Options> as children in Menu.jsx might need some re-work.

@neilpfeiffer From UX perspective should the user be allowed to navigate <OptGroup> using keyboard while ScreenReader is Off ??

[ShettyAkarsh]

@dev-cprice , @lokesh-0813, can we implement something like for the screen reader set the aria-label text such as concatenating the optgroup name and the option selected. so that user could come to know under which group the option is selected ?

[scottwilmarth]

@lokesh-0813 to answer your question whether or not sighted keyboard-only users would expect to navigate to an OptGroup, the answer is no. Ideally, the keyboard-only user would not navigate to the OptGroup. However, if that is our only option to ensure desktop screen reader users have the OptGroups announced, it is a fairly minor compromise. That is with the caveat that the keyboard-only users would not be able to select the OptGroup.

[ryanthemanuel]

@lokesh-0813 @ShettyAkarsh let's go with the option to highlight (but not select) the option group as @scottwilmarth suggested.

[jeremyfuksa]

Removing the UX block because it looks like it was accidentally added back in after @ryanthemanuel removed it.

[lokesh-0813]

@ryanthemanuel @scottwilmarth I enabled keyboard navigation for the <optGroup> and below is the result.

We need new styles to differentiate optGroups from options when consumers navigate via keyboard to avoid confusion. The Screenreader picks up optGroups and announces the content after enabling keyboard navigation.

CC: @neilpfeiffer

[jeremyfuksa]

@neilpfeiffer and I were discussing, and we think the <OptGroup> shouldn't have a visual indicator on focus because only interactive elements should have visual focus. However, for sighted users that are using keyboard navigation, this lack of visual indication might give the impression that there is an error.

EDIT

Based on some quick research, since our OptGroup is a list item with a group role, we could use aria-labelledby to read the contents of the group label as the label for the listbox. That way, we could skip explicit keyboard focus on the group headings, keeping accessibility while allowing for a more expected behavior for sighted users.

Reference

• https://www.w3.org/WAI/tutorials/forms/grouping/#grouping-items-in-select-elements
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_group_role

[lokesh-0813]

@jeremyfuksa aria-labelledbyapproach was tried before and the drawback is the screenreader shows the <optgroup> text but is immediately overridden by <option> text. It is difficult for human eye to catch the transition and the message is not audibly read out.

Above phenomenon happens because of this. We have a visually hidden component for the screenreaders to pick the text to read. So every time this visually hidden component overrides aria-labelledby. Although it could be handled with a timeout, its gonna cause different set of problems and will not be smooth and interactive.

From what I notice we could try two approaches(without enabling keyboard access to optgroups )
1 - We could announce appropriate <optgroup> labels along with the options every time consumers navigate via keyboard.
2 - We could check the index of first and last option of every <optgroup> and announce optgroup labelswhen user navigates to one of the indexes.

Let me know your thoughts.

[jeremyfuksa]

1 - We could announce appropriate <optgroup> labels along with the options every time consumers navigate via keyboard.
2 - We could check the index of first and last option of every <optgroup> and announce optgroup labelswhen user navigates to one of the indexes.

Let me know your thoughts.

Let me continue to research this and I'll get back to you soon.

[jeremyfuksa]

In option 1, are you saying that a keyboard user would hear something like the following in my hypothetical optgroup?

e.g. "Group Droids, R2D2. Group Droids, C3PO. (navigates to next group) Jedi, Luke Skywalker."

[lokesh-0813]

In option 1, are you saying that a keyboard user would hear something like the following in my hypothetical optgroup?

e.g. "Group Droids, R2D2. Group Droids, C3PO. (navigates to next group) Jedi, Luke Skywalker."

@jeremyfuksa Yes, exactly. I think we could do either way(announcing the groups at the end like "R2D2, Group Droids etc)

[jeremyfuksa]

OK. That sounds good. Let's give that a shot.