[EuiComboBox] Blur upon selection when singleSelection is defined#7279
[EuiComboBox] Blur upon selection when singleSelection is defined#7279nickofthyme wants to merge 1 commit intoelastic:mainfrom
singleSelection is defined#7279Conversation
singleSelection is defined
|
Preview staging links for this PR:
|
💚 Build Succeeded
|
There was a problem hiding this comment.
Unfortunately, this is a no-go from an accessibility point of view. Blurring the input strands focus/kicks the active element all the way back to on the <body>, which completely throws off screen reader and keyboard user UX.
It's not clear to me what the goal here is of blocking re-focus on the combobox after single selection. Why exactly is that a problem?
CC @1Copenut for accessibility expertise
|
Yeah this came up in elastic/kibana#166024 (comment)
Which I agree, it's strange for a single select element to re-focus on itself (specifically the search input), the only reason to refocus would be to add more values.
Is it possible to fix this by focusing the containing element of the In any case happy to close if not desirable |
1Copenut
left a comment
There was a problem hiding this comment.
Cee asked me to review this PR, so I ran through it with four input forms. Assume screen readers were paired with preferred browsers.
- Keyboard only
- Mouse only
- Keyboard + screen reader (VoiceOver, NVDA, JAWS)
- Mouse + screen reader (VoiceOver, NVDA, JAWS)
Cee called out the change stranding focus on the <body> tag for mouse users. This is a different experience from keyboard users where the input retains focus after a selection is made. That break in UX is made worse for screen reader users who navigate with a mouse because the expectation would be the combo box still have focus.
If users try to use the arrow keys to make a quick change like they would a standard <select>, they'll scroll the page instead.
I agree with Nick that it'd be excellent to drop the cursor when a selection is made, more in keeping with standard select menus. I would also say if we can't have that and return focus to the combo box when a selection is made, we should leave the component working as it does on production.
Standard select menus don't have a search, so I don't think this is 1:1 UX. I do see WAI-ARIA's example combobox w/ autocomplete does remove the caret on select however: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/ What's interesting is that the above example does not remove the caret on click for keyboard users (selection made via up/down arrow and enter keys) but does remove the caret/input focus for mouse users. I really don't love the idea of making event exceptions like that however, it feels like it'll make our JS code more convoluted and harder to test. If the flashing caret is all that's "bothering" people in terms of UX, I wonder if we could find a visual workaround via CSS instead where we simply visually hide the caret but leave focus on the input. It looks like we could use |
Yeah very true, this is really a combination of the I think it would be helpful to improve the focus state of the With the The only reason I mention this inconsistency is to provide an alternate to blurring the entire component, as currently done in the PR, and instead blur the focus of the input to the parent wrapper component ( In the end, this was simply an observation while reviewing a PR in kibana that I felt was a little strange, which was independently raised by others without even eliciting their input on the matter. All that said - I see this has differing ideas and I'm fine closing this PR, I also don't see a point in hiding the cursor, as an alternative. |


Summary
This PR changes the blur behavior of the
EuiComboBoxfor single selections.Now when
singleSelectionis set, eitherasPlainTextor not - Upon selection of a value the refocusing of theEuiComboBoxInputis prevented effectively blurring theEuiComboBox.Fixes #7169
Before
After
Context
I did not implement a
blurandfocusmethod on theEuiComboBoxitself as I suggested in the issue, because I think this type of change should be applied to all custom input elements and not just theEuiComboBox.QA
General checklist
@defaultif default values are missing) and playground toggles