Screen reader read's selected value as 'blank'

[ericj17]

Hi there,

I am noticing that a screen reader (NVDA and WIndows 10 Narrator) is unable to read the selected value in the react-select field. NVDA will read it as 'blank' (see screenshot below).

To reproduce using NVDA screen reader:

1. tab to the react-select field
2. the screen reader will read the combo box as having a value of 'blank' even though a value is selected

Any suggestions on how to rectify this so that screen readers can read the value selected in the react-select field?

Thanks and Regards,
Eric

[meditatingCybermind]

I also was looking into this issue and thought it was related to role="listbox" or role="combobox" not being assigned to the parents of the elements with role="option", but this did not solve the issue. NVDA reads out "blank" whenever it focuses on an empty line, though it will say "blank" even if searchable is false.

[IrinaBadiginaEpam]

What is the status of the issue?

[acromarco]

As a workaround I append the selected Option to the aria-label. The tricky part is, that now the screen reader (NVDA) will still read the old value when the user selects a new value. As solution to this problem, I don't append the selected Option to the aria-label while the select menu is open.

<ReactSelect
  aria-label={'My Label' + (this.state.isOpen ? ` Option ${selectedOptionLabel} is selected` : '')}
  onMenuOpen={() => this.setState({isOpen: true})}
  onMenuClose={() => this.setState({isOpen: false})}
  // ...
/>

I'm not sure whether this is a good solution, but at least the screen reader now get's information about the selected option.

[ebonow]

Greetings and apologies for the long delay in a response from the collaboration team.

I noticed that this is a screenshot from v1 and was wondering if this is still an issue for v2 or v3? I am uncertain what accessibility strategy was used at the time, but for now, aria-live is being used for a11y.

Based on the behavior, I would be apt to believe that the screenreader is reading "blank" because the input is cleared on blur. It would seem reasonable to perhaps set the aria-label onChange, onBlur, or perhaps even onFocus depending on timings.

I want us to be able to address accessibility in an intelligent way, and for now that focus is on aria-live for v3.3, but we will continue to look into ways to support WIA-ARIA following that to ensure that we are not introducing conflicts related to competing audio cues.

I will be marking this as awaiting-author-response to see if there is anyone that confirm that this is still an issue within the library or if this is simply expected behavior. I also am not sure what the status of this is versus aria-live, so please feel free to add any findings so we can appropriately handle this issue.

[ebonow]

As an update, I have spent a bit more time with the aria-live implementation. This is indeed an issue that I have documented and added as a to-do as part of all known aria-live issues in #4414

[skippone]

I've been investigating this issue (using the latest 4.1 version) and I believe the reason NVDA (and perhaps other readers too) reads "blank" is because the input field is focused all the time.

Once the menu is opened the input field should not yield focus, the menu should be focused instead. The accessibility of the menu, options and input field would also be greatly improved if the following aria attributes would be added together with the focus change:

<Input> component

• role: "combobox"
• "aria-autocomplete": "list"
• "aria-expanded": menuIsOpen
• "aria-owns": MENU_LIST_ELEMENT_ID

<MenuList> component

• role: "listbox"
• id: MENU_LIST_ELEMENT_ID

<Option> component

• role: "option"
• "aria-posinset": props.options.indexOf(props.data) + 1
• "aria-selected": props.isFocused
• "aria-setsize": props.options.length

There is quite a good post on the topic of accessible autocomplete at https://adamsilver.io/blog/building-an-accessible-autocomplete-control/.

I was trying to workaround the focus input issue using custom component but so far have not been successful.