(Accessibility) [EuiSelectable] Unable to make selections when second interactable element in focus

[Heenawter]

For Dashboard input controls, we give users the ability to both search and filter the items in the EuiSelectable component as part of the creation/editing process:

To accomplish this, we are currently using the searchable prop and adding our filter component between the native search and list, like so:

<EuiSelectable
  searchable
  ...
>
{(list, search) => (
  <>
    {search}
    <EuiSpacer size={'s'} />
    {fieldTypeFilter} // this is our custom filter component
    <EuiSpacer size={'s'} />
    {list}
  </>
)}
</EuiSelectable>

Unfortunately, this messes with the a11y support that was added to the EuiSelectable component, since it seems to assume that all children should retain focus as the user navigates the list. This works great when the search is in focus, but it gives a confusing experience when the fieldTypeFilter is in focus, like so:

In the above GIF, you can see that, while the fieldTypeFilter is in focus, the user is unable to make selections in the list despite it giving the appearance that they should be able to. It would be nice if only the search child retained focus in this way, whereas any other children did not - or, perhaps, if there was a way to control whether or not a child retained focus.

[cee-chen]

Here's the code that impacts this particular issue:

eui/src/components/selectable/selectable.tsx

Lines 335 to 359 in 784a553

	// For non-searchable instances, SPACE interaction should align with
	// the user expectation of selection toggling (e.g., input[type=checkbox]).
	// ENTER is also a valid selection mechanism in this case.
	case keys.ENTER:
	case keys.SPACE:
	if (this.props.searchable) {
	// For searchable instances, SPACE is reserved as a character for filtering
	// via the input box, and as such only ENTER will toggle selection.
	if (event.target === this.inputRef && event.key === keys.SPACE) {
	return;
	}
	// Check if the user is interacting with something other than the
	// searchbox or selection list. If not, the user is attempting to
	// interact with an internal button such as the clear button,
	// and the event should not be altered.
	if (
	!(
	event.target === this.inputRef ||
	event.target ===
	this.optionsListRef.current?.listBoxRef?.parentElement
	)
	) {
	return;
	}
	}

Lines 350-358 are what's causing this "problem". That early return was originally added to prevent selection from happening when the search clear button was 'pressed' (via enter or space key). In theory, however, it applies to literally any wildcard custom content inside the <EuiSelectable> as well.

So for example, if you added a custom button below the list that did some custom action (opened a modal, sent an email, loaded more items, etc.), wouldn't you want that item to not accidentally trigger selection as well? In theory, BTW, pressing Enter on your custom filter dropdown/button should be toggling its associated popover only, not triggering a selection.

In theory, what would be a "complete" fix would be to also prevent the up/down arrow keys from changing selection if the searchbox or listbox isn't the current focus. However, I totally get the filter behavior you've added and that you want it to behave the same way / as seamlessly as the searchbox itself. I'm just not really certain there's a way to implement that while also implementing a way to ignore keydowns on children that shouldn't trigger selections.

My personal instinct/recommendation for a fix would be:

1. On filter selection or popover close, you should return focus manually to the EuiSelectable search input (restoring default keydown functionality) - you can access this input via <EuiSelectable searchProps={{ inputRef: yourRef }} />
2. On EUI's side, we'll tweak our keydown event handler to return early for all events if the focus is not on either the searchbox or the listbox (meaning that the current misleading up/down behavior will not occur when focus is on the filter button).

Thoughts? This is definitely a complex problem to solve without a single clear/easy fix, FWIW.

[Heenawter]

However, I totally get the filter behavior you've added and that you want it to behave the same way / as seamlessly as the searchbox itself.

My main issue was simply the fact that, when our filter dropdown has the focus, there was still a visual indicator in the listbox that makes it seem like you can still make a selection. That, combined with the fact that the listbox still responds to arrow key presses when the filter dropdown is in focus, made for an overall pretty confusing experience.

I'm just not really certain there's a way to implement that while also implementing a way to ignore keydowns on children that shouldn't trigger selections.

100% agree! I don't know how that would work. If selections are only possible when either the search or listbox is in focus, and we remove the visual indicators that suggest otherwise when the filter dropdown is in focus, I think this is a good enough fix for this case.

Thanks for the thorough response, @cee-chen - your suggested fix makes total sense to me! 💃