Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility: no way to clear the selection with a keyboard #4988

Open
dgreene1 opened this issue Jan 11, 2022 · 14 comments
Open

Accessibility: no way to clear the selection with a keyboard #4988

dgreene1 opened this issue Jan 11, 2022 · 14 comments
Labels
issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet

Comments

@dgreene1
Copy link

Caveat: I'm not an accessibility expert so perhaps there is an alternative mechanism available to clear selections. But the usual way (tabbing to the clear button) is not working.

Reproduction Steps

  1. open NVDA
  2. visit https://react-select.com/
  3. tab to any select example that has a selected item and that is clearable (at the time of this writing the first example satisfies these conditions)
  4. tab again

Expected Behavior

I would expect Step 4 to focus the "X" that clears the selected option.

Actual Behavior

You can't focus the clear button.

Proposed Solution

Make the clear div a button tag.

Am I Willing To Submit A PR For This?

Yes, absolutely. The company I work for has budget for fixing a11y issues in the open source libraries we use or that we are considering using.

@dgreene1 dgreene1 added the issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet label Jan 11, 2022
@LauRoxx
Copy link

LauRoxx commented Jan 24, 2022

The mechanism for clearing options currently via the keyboard is backspace. However I agree that having a visible control that cannot be focused by tabbing could be confusing for those who are sighted but cannot use a mouse.

@dgreene1
Copy link
Author

Yes, whatever keyboard key we choose (space works for me) we need to give it tabIndex.

would a PR be accepted for this?

@Rall3n
Copy link
Collaborator

Rall3n commented Feb 7, 2022

Hello @dgreene1 and @LauRoxx,

react-select tries to follow the combobox W3C spec.
The spec dictates the following regarding keyboard interaction or more specific, tabbing:

Tab: The combobox is in the page Tab sequence.
Note: The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.
source

In other words, sub-components should not be able to be focused by pressing the Tab key.

The intended way to clear the selection using a keyboard is by pressing the Delete key, with Backspace being an alternative (source).

Would a PR be accepted for this?

You can create a PR which changes the div to a button, but that would only be acceptable if it behaves the same as without the PR in regards to default tabbing behavior. It should allow for developing users to change the behavior more easily by omitting relevant props (aria-hidden, tabIndex) instead of recreating the whole component.

@dgreene1
Copy link
Author

@Rall3n I agree to the spec but it’s just sad for the user that it’s a bit confusing. I concede though because following specs allows us to provide a common mental model for users so they can “port” their experiences from one application to another.

FYI, your links to the authoring guide above are stale or wrong so I have it here: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/

thank you for the insight.

@dgreene1 dgreene1 reopened this Jul 29, 2022
@dgreene1
Copy link
Author

dgreene1 commented Jul 29, 2022

On second thought, @Rall3n i just re-read the combo box authoring spec and it refers to the popup button or children of the popup. The clear button is neither of those things. So can you clarify why it would break the spec to make clear tab-able?

Note: The popup indicator icon or [popup indicator] button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.

@LauRoxx
Copy link

LauRoxx commented Aug 1, 2022

@dgreene1 I don't believe you should take the absence of these elements from the tab sequence exclusions as meaning they're allowed in the tab sequence. The patterns do not account for a multiselect where selected options are listed outside the listbox. Visually we are showing them as being part of the combobox so I believe @Rall3n is correct in saying they should not be in the tab sequence.

@g-akshay
Copy link

g-akshay commented Oct 4, 2022

Hi @Rall3n, any further thoughts on whether the change will be incorporated?

@cabillin
Copy link

cabillin commented Nov 1, 2022

The problem is that everything that can be done via the mouse should be supported via the keyboard. Delete/backspace only deletes a single item, so there is no equivalent for the clear button. Our company's internal accessibility review has also flagged that fact that the clear button is not keyboard accessible.

I disagree with @Rall3n's & agree with @dgreene1's interpretation of the W3C requirements. It is true that the requirements say "The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.", but the clear button is not the popup indicator/button nor is it a popup descendant. The W3C requirements do not include any mention of the clear button, so we can choose to treat it however we want (as long as it is keyboard accessible).

Even if we want to exclude the clear button from the page Tab sequence, we can still make the clear button accessible to keyboard users. This can be achieved by having it accessible via the L/R arrow keys while the tab focus is on the combobox (similar to the behavior of the navigating between the clear buttons of the individually selected items in the multi-select case).

@mzibra
Copy link

mzibra commented Dec 6, 2022

Hi just found this control and its pretty nice, however keyboard navigation for delete and marking etc are really basic for instance I use shift-home and then delete a lot, to quickly mark a line current line when I am typing and I change my mind.

Use case search for a user in a multiselect by name, then decide you want another one, then you do shift-home delete, and start typing again.. Now I need to backspace x times to delete all the characters. I didn't realise how often I use shift-home, delete until it wasn't there in this widget.

@SairamAlagapan
Copy link

SairamAlagapan commented Mar 22, 2023

Any update on this?

@mattotx
Copy link

mattotx commented Apr 24, 2023

I'm looking into fixing this

@mellis481
Copy link

@mattotx Perhaps you can make the clear button being keyboard-accessible opt-in behavior.

@SairamAlagapan
Copy link

@mattotx Any update on the fix?

@mellis481
Copy link

Just to make sure it doesn't get lost in a PR (#5850) that will likely get closed, I wanted to share what was discussed there that is relevant to this topic.

@jossmac found the WCAG spec that addresses keyboard interaction expectations for combobox controls (which is what react-select is):

Escape: Dismisses the popup if it is visible. Optionally, if the popup is hidden before Escape is pressed, clears the combobox.

As far as what is currently implemented at this time in react-select:

  • DELETE and BACKSPACE will clear input if the popup is not visible.
  • DELETE and BACKSPACE will not clear input if the popup is visible.
  • ESCAPE has no effect on clearing input.

With regard to clearing react-select instances, it's my belief that react-select MUST be updated to support the clearing of input when ESCAPE is pressed when the popup is not visible. This will make it WCAG-compliant and will make the desire to have the clear button be keyboard focusable moot. Which is a good thing considering there is a contingent of people who found that approach undesirable with the argument that adding an additional tab stop to a form creates a bad user experience.

Hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet
Projects
None yet
Development

No branches or pull requests

9 participants