Feature Request: Skip keyboard navigation of disabled options

[audriusnavickasDB]

Current results:

• When isOptionDisabled prop is present, it disables all selecting option value events (click, keyboard), but does not skip it's focus via keyboard when clicking arrow keys up and down.

Expected results:

• If option is disabled, when navigating via keyboard it should skip it. The focus should go to another available option. Example, default select behavior: https://jsfiddle.net/zm7uanxo/1/
• It worked like this at least in v1 of the plugin, when I tried it.

[luke-webdev]

I was looking into this and there's actually a test that verifies disabled options to be focusable.

https://github.com/JedWatson/react-select/blob/master/packages/react-select/src/__tests__/Select.test.js#L806

I was wondering if this is really the expected behaviour because the native element skips disabled options. It would be nice to give the user the ability to control skipping vs not skipping as we have a requirement to skip the disabled ones. Edit: Looks like this was intended to apply accessibility to disabled options: #3445

[audriusnavickasDB]

In my opinion focusing the disabled option provides no benefit. You can focus the option, but you cannot do any actions with it. It's just adds additional action for user to press arrow key one more time to move to other option.

If it is intended, I believe just like @luke-webdev mentioned it would be great to have an additional prop to allow or ignore focusing disabled options.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#attr-disabled for example here, it is mentioned that browsers will ignore even the focus related stuff. So when you try, and see that it ignores, automatically you would expect to have same behavior here.

[luke-webdev]

My proposal is to add a skipDisabled boolean prop that defaults to false to maintain backwards compatibility.

I can work on creating a pull request for this issue if this is okay.

[llell8]

i wonder if there is an option to make disabled option not only selectable/unselectable but also clickable/unclickable... thus the disabled options will have they own class and will be visual recognisable as disabled but users will be able to click them..

[ramraphael]

Jumping in to confirm this issue. Happy to take this on with some guidance from more experienced maintainers.

[luke-webdev]

@ramraphael There is an open pull request for this issue, that is waiting to be merged. Can someone with write access complete it please?

[gustavshf]

Having the same issue

[ebonow]

Greetings @audriusnavickasDB and all,

The topic of disabled options been discussed before. To be clear, the functionality was originally changed to the existing behavior in order to properly support accessibility and not the other way around. #3354

Regarding native select behavior, here is your own example when arrowing down to a disabled option with VoiceOver enabled:

It's reasonable to say that disabled is meant to be a visual clue indicating that some criteria disqualifies it from being selectable and that this indication should also be supported by assistive technology. The team would like to encourage best practices when it comes to accessibility, so it would seem that this feature request is an anti-pattern for accessibility.

This criteria likely disqualifies this as a candidate for inclusion into a future release. Please not that it is a difficult balance to add new features that people have put the time into developing and testing vs the added complexity and code weight of adding and supporting a new prop. I defer to the argument that this library is not meant to be everything to everyone but rather to provide the tools to be anything to anyone.

With that said, I would be open to discussing how a developer might be able to implement this functionality without changing the source code and using the existing apis. If there are gaps, we can explore adding some more universal api methods that would be beneficial to a larger group of developers.

One such feature might be an internal method such as setFocusedOption that could use some criteria to identify a visible option based using the data and index. This seems relevant to user requests who also do not want to select an option by default or may wish to include some other focus criteria so that focusing an option is not dependent on the sort order.

[Eli-Black-Work]

Hi @ebonow 🙂

Thanks for the detailed feedback 🙂

Although I agree that it's important for react-select to be accessible, it seems that native <select> elements do not let the user focus disabled options with either the keyboard or the mouse, so I think that react-select's behavior differs from what end users would expect, given their experience with native <select> 🙂

For example, for the code below, if the user presses the down arrow key while Option 1 is selected, then Option 2 will be selected. "Disabled option" is skipped entirely.

<select>
  <option>Option 1</option>
  <option disabled="disabled">Disabled option</option>
  <option>Option 2</option>
</select>

Given this, my personal thoughts are:

• react-select should mimic the native <select> in regard to disabled options (that is, they can't be focused with either the keyboard or mouse)
• react-select should be accessible

Thanks again, and would you to hear your thoughts on the above, when you have time 🙂

[ebonow]

@Bosch-Eli-Black thanks for the thoughtful reply.

My testing for accessibility was done with OSX Voice Over activated which may explain why your experience does not match with what is shown in the screenshot as I do recall that Voice Over had to be enabled to impact the behavior of how disabled options are handled with arrow keys.

This type of walled garden OS level conditional behavior makes it difficult/impossible for open source libraries like react-select to emulate so it does come down to having to make a choice (either within the library or by the dev), but I fully agree that react-select should be accessible which is why the current behavior was changed to what it is today.

We do have a dedicated team of people who will be looking further into accessibility. I took a shot at trying to improve many facets of the aria-live implementation, but lacked the time and resources to do a more comprehensive look into what works for different accessibility tools on different OS's.

There is an argument to be made in emulating the behavior of a select for the +99% of the users who do not rely on assistive technology as ultimately we are here to support a user's experience and expectations, so I think it is worth keeping this open though this likely belongs in the Discussions area so we can focus on resolving issues here.

[Eli-Black-Work]

Thanks, @ebonow 🙂

Indeed, if OSX (and maybe other platforms) changes the behavior of <select> based on whether voice-over is enabled or not, it sounds like it'd be hard to emulate. I wonder if one approach would be for react-select to create and focus a hidden <select> element, then change the focused option in react-select based on what's focused in the native <select>. That way, if the user is able to focus disabled elements in the native select, they'd be able to focus them in react-select, too.

Of course, that approach might not work on smartphones, since their native <select> elements are pretty different from ones found on desktops.

For now, would you be okay with my opening an issue to change the behavior of react-select so that it does not allow focusing disabled options? Although I agree that accessibility is important, I think that in this case, making react-select accessible for the visually impaired pretty significantly degraded the user experience of non visually impaired users.

[ebonow]

The existing behavior is intentional and by design so categorizing this as an issue would be inaccurate. Separating feature requests from issues is intentionally meant to prioritize fixing broken behavior or at least make it easier to identify known defects to users quickly trying to understand why something isn't working.

That said, I would happily defer to @seancurtis to get his opinion on how allowing users to skip over the selection of disabled menu options fits in with best practices for accessibility.

[seancurtis]

Yeah unfortunately it's not really possible to sniff for whether a screen reader is enabled.

Often accessibility issues are also UX issues for sighted users — eg. if you have an item that's disabled and skipped, why is it even in the list in the first place? We often have tooltips or another bit of info explaining why something is disabled, and in order to show this they'd need to be focused.

That said, react-select has a very flexible API and I could see a case for it, but personally I dislike providing people with a "foot gun" prop, even if we provide a caveat/warning about using it.