[BUG] "Grouped" options breaks screen readers

[carsonpowers]

Using the "grouped" feature breaks screen readers.

Because group sub-component elements exist as the first item underneath menuList; aria readers will think that the dropdown list contains however many group elements there are, NOT however many option items there are, like it should.

To reproduce

1. Navigate to the "Grouped" example on the main react-select homepage: https://react-select.com/home
   
2. Focus the grouped example element with NVDA (or JAWS) enabled.
3. Click spacebar to open the menu.
4. Click down the the keyboard arrow keys until the option "Purple" is selected.
5. Screen-reader will call out that the element is in position "0 of 2" despite the fact that there are 14 items in the list and purple is the third member of that list; it should read "3 of 14".

It's saying 0 of 2 because it's counting the number of group elements under menuList (Colors and Flavors), not the Options nested further down inside Group.

Note> Adding role="presentation" to group may fix this issue.

[ebonow]

There has been some discussion also about supporting nested options so I am not sure if there is a recommended approach for having screen readers handle both this current implementation as well as the proposed solution correctly.

I'm hoping to address many of the a11y issues with this into a near future release and would certainly appreciate any support from those who have deeper experience in this area to contribute whatever they know about appropriate syntax and best practices.

[ebonow]

@carsonpowers I have been attempting to read a bit more about how screenreaders handle optgroup. It appears that OSX VoiceOver does indeed list all of the options under the total amount, but additionally, optgroup tags are focusable but disabled. I have also read that WAI-ARIA has poor support for optgroup so it's also unclear to me what could/should be done for that approach.

From an accessibility perspective, I am curious if @kylemh has any thoughts regarding best practices for supporting groups.

[kylemh]

Coverage without using optgroup exists here FWIW; however, semantic markup is always preferable...

Where did you read about there being poor support for optgroup? Obviously, this doesn't look ideal...

I'm interested in hearing from a JAWS user on grouped dropdown items. I've never looked into grouped select options.

[ebonow]

I read that opinion here but it's also worth mentioning that the article is over 9 years old... so there's that.

Here is another article I came across from a few years ago that shows a few different representations of how different SR's treat optgroup which shows a bit of variation

I'm interested in taking on aria-live support for this, but unsure what expectations would be.

@carsonpowers it appears that SR behavior can vary. Does this behavior noted from the second link seem accurate to you, or is this out of date?

Screen Reader + Browser	SR behavior
JAWS 17 + IE 11	SR announces the option value along with label name.Ex: Apple (Fruits), Banana(Fruits)
NVDA 2015 + FF 47	SR does not announce the label when options are not expanded. But when user hits space key, the options list expands and SR announces as Fruits grouping – Apple 1 of 3 – Level 2 for each of the options.
Voiceover iOS9 + Safari	Screen reader appends the word ‘heading’ for labels (Fruits, Juices…)Ex: Fruits Heading, Apple, Banana
Talkback V6.0 + FF	Screen reader appends the word ‘disabled’ for labels (Fruits, Juices…)Ex: Fruits disabled, Apple, Banana.

What seems most relevant and at what point?
It seems reasonable with aria-live that when new results are returned we announce the total, and then as they focus on new options we can give them the count within the group:
ie: "7 items, focused on "Apple, Fruit, 1 of 3"

WIA-ARIA support for groups might be a bit more complicated, so interested in how we might want to approach it.

[dgreene1]

Are there any updates on this?