[EuiSearchBar] Add the option to render a hint below the bar

[sebelga]

As part of the work the improve UX for the <TableListView /> in Kibana (the page rendering the list of dashboards, visualisations, maps) we want to be able to render a hint under the table search bar when the field is in focus.

We will need to add a new prop to the search bar (hint) that accepts a string or ReactNode to be passed.

Design

[chandlerprall]

Sounds good to me. Thinking through what happens as the user types, I think any hint passed should always be rendered and it's up to the app to remove/modify in response to the user. That would allow more flexibility to provide hints against the content.

@1Copenut what accessibility rules should we ensure to follow here? e.g. linking the hint to the input with an aria-describedby or similar.

[1Copenut]

Yeah, I think aria-describedby is a good use here. Is there a chance this will be used on mobile screens and/or the hint would be covered up by a typeahead? If either of those are true, would a visible label + hint above the input be appropriate?

[sebelga]

Is there a chance this will be used on mobile screens and/or the hint would be covered up by a typeahead

Do you mean to render 2 different UIs depending if we detect that we are on mobile? If not we render the above design and if we are we render the hint below the label?

[1Copenut]

Not specifically, I'm more asking a question. I'm all for consistency and brought it up because I'd seen that happen in past stops. Placement and UX aside, an aria-describedby is a great way to tie the hint text to an input semantically.

[cchaos]

Consider the hint as just a popover footer. If the search has typeahead, thats' the main popover content with the hint being at the bottom in the same container. If there's not typeahead, it's just the footer/hint. So not two UI's.

[1Copenut]

Following on what @cchaos said, I have one addenda for automated test suites. If the hint (aria-describedby) block is in the typeahead footer, you will need to add the attribute to the input dynamically when the typeahead is shown. Otherwise the input will have an attribute looking for an ID that's not in the DOM, and automated a11y tests will throw an error.

<main>
  <h1>ARIA describedby test</h1>
  <label for="input-test">Your name</label>
  <!-- Text element with id="input-hint" must be in the DOM **or** -->
  <!-- aria-describedby must be removed until the ID is present -->
  <input aria-describedby="input-hint" id="input-test" type="text" value="" />
</main>