Repository navigation
[BUG] "Grouped" options breaks screen readers #4277
Description
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
- Navigate to the "Grouped" example on the main react-select homepage: https://react-select.com/home
- Focus the grouped example element with NVDA (or JAWS) enabled.
- Click spacebar to open the menu.
- Click down the the keyboard arrow keys until the option "Purple" is selected.
- 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.
Reacted by Eric Bonow
Activity
ebonow commentedon Dec 6, 2020
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 commentedon Jan 17, 2021
@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 foroptgroupso 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 commentedon Jan 17, 2021
Coverage without using
optgroupexists 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 commentedon Jan 18, 2021
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?
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 commentedon Mar 4, 2022
Are there any updates on this?