[EuiSelectable] Behavior of using Home and End key in searchbar

[wenchonglee]

Hey,

In EuiSelectable (and EuiSelectableTemplateSitewide by extension), the Home and End key is currently configured to move around the options, as seen in the following snippet:

eui/src/components/selectable/selectable.tsx

Lines 272 to 285 in db3ddc1

	case keys.HOME:
	event.preventDefault();
	event.stopPropagation();
	this.setState({ activeOptionIndex: 0 });
	break;
	case keys.END:
	event.preventDefault();
	event.stopPropagation();
	this.setState({
	activeOptionIndex: this.state.visibleOptions.length - 1,
	});
	break;

I've received feedback from my users that they expected the Home and End key to behave differently.

In the scenario they encountered, they typed a search term and found no results. Realizing their mistake, they tried using the Home or End key to move around the text and make adjustments to their search term. In this scenario, it does nothing because there were no results shown and it leaves them confused.

I'm sure the eui team has your own considerations for the alternate behavior, but seeing that the team plans to use EuiSelectable in more components (#4054), can I suggest an option for outside consumers to opt out of this behavior?

Please let me know if this is not something the team is keen on

[myasonik]

🤔 Thanks for bringing this to our attention!

So the reason we do this is because it is recommended by the ARIA practices spec but it looks like in the latest version it tweaks it slightly to only recommend the custom behavior if the text isn't editable.

Though I guess you could build a non-editable combobox with our base components, I don't think that's a specific use case for us so maybe we just get rid of this all together.

[chandlerprall]

This makes sense to me, especially as we keep the text cursor in the input even when the options list is "active".

[akashgp09]

working on it

[wenchonglee]

That was quick!

Thanks @myasonik for linking both ARIA specs, I had no idea they included comboboxes 🧐