[EuiSelectableTemplateSitewide] Allow for default enter key action

[i-a-n]

hi team, after raising this thread with Chandler, he recommended we create an issue to address our concern: we'd like to configure EuiSelectableTemplateSitewide in such a way that the default behavior when entering a search term -> results load -> pressing the enter key can trigger an event of our choosing; in our case, we want to execute a sitewide search on a results page.

currently, entering a search term -> results load -> pressing the enter key will always lead the user to selecting the first search result in the popover.

I think we're officially agnostic on how to best implement this, but our suggestions seemed to be (in order of preference) 1. allow a "default selection" element selector to be passed in, so we can specificy the "View more results" link be the default selection when search results are first populated, 2. allow an arbitrary pseudo-result to be injected first in all search cases, allowing us to inject a "Search the site" item, 3. allow an "empty" default selection and a function to be passed when the enter key is pressed, so we can pass a navigate function to be executed if a user hasn't used the arrow keys to navigate through the results.

thanks for your time!

---

Related issue: https://github.com/elastic/eui/issues/6375

[chandlerprall]

3. allow an "empty" default selection and a function to be passed when the enter key is pressed, so we can pass a navigate function to be executed if a user hasn't used the arrow keys to navigate through the results.

this is the direction I'm leaning as this aligns with similar search bars I spot checked around the web, but will discuss design & accessibility implications with the team

[1Copenut]

Fair warning, this will be a wall of text.

Problem statement:

We want a way for the sitewide search component to let users execute a full domain search or pick a suggested result based on what they type. These two user flows must be fully accessible with a high degree of discoverability.

Current implementation:

Our sitewide-search component does the following:

1. It auto-selects the first suggestion when users start typing
2. It allows users to press Ctrl/Cmd + K to make an async search call
3. It allows users to click on a "View more options" button to show all search results
4. It does not allow users to press the Enter key to take a default action

Proposed change:

Our iterated sitewide search would retain existing functionality, with a few differences:

1. Continue to show suggested results when users start typing. Current mouse, keyboard, and screen reader behaviors would be retained, except:
2. NOT auto-focus the first suggested result when users are typing. Users could still click or press DOWN_ARROW to select a search result. Pressing Enter would search on that result. Additionally:
3. Allow the "View more options" button to receive keyboard focus. This item would require the popover to stay open on Tab keypress. Pressing Enter when "View more options" has keyboard focus would take users to a search results page. Clicking "View more options" would have the same effect.
4. Allow users to press Enter while the text input still has focus. This would also take users to a search results page.

The difference in behavior is subtle. Our current implementation is a List autocomplete with automatic selection. This is an example of WAI-ARIA combobox pattern 3. I am proposing we move to pattern 2, list autocomplete with manual selection.

Combobox pattern 2 says users can select a suggested result by pressing an arrow key or clicking a result. This is an opt-in pattern that allows us to add a second path of "search everything" by pressing Enter from the input or clicking "View more options."

We can extend the SR-only instructions to describe this new "Press enter to search all results" workflow and amend them to say "Press down or right arrow to select a suggested result." Screen readers will always announce the number of suggested results as users type.

I feel like this gets to the heart of the original description without disrupting user expectations of the combobox pattern or introducing new/unexpected focus behavior for assistive technology users.

[1Copenut]

@constancecchen has raised a great point about the current sitewide search:

The link in the popover footer should not be tabbable, and to be honest, looking at the example / our code, I think we should consider removing the ability to add custom footer content to EuiSelectableTemplateSitewide altogether - it is indeed completely inaccessible to SR users

If we're adding a press Enter to view all search results a'la Gmail, this button might be unnecessary. If we remove "View more options", do we need a "Search" or "Go" button to afford mouse users the same search all results as keyboard users? Going back to the Gmail model, users can click the :mag_right: after entering a search term to execute, same as pressing Enter.

[1Copenut]

Another great suggestion from @constancecchen

The footer is interesting to me because we just added a similar "hint" behavior to EuiSearchBar: https://github.com/elastic/eui/pull/6319

Personally my vote would be to allow for a very limited footer via a specific prop like hint="", that has all the right aria-describedby labels set by EUI and only allows text / disallows interactable children from consumers

That should allow for Search with Command + / text and similar without letting consumers render content inaccessible to screen readers

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions[bot]]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.

[cee-chen]

Going to re-open this as it has a fairly detailed writeup from Trevor that feels achievable

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[tsullivan]

Hi, I have deleted this comment. Have a great day!

[github-actions[bot]]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.