SearchInput - update input type to text

[thatblindgeye]

Is this a new component or an extension of an existing one?
SearchInput

Describe the feature
Based off of conversation in patternfly/patternfly#5210 and its linked PR.

tl;dr is type="search" for a text input can cause a browser rendered clear icon that isn't keyboard focusable to render, but not all browsers do (Firefox). Instead we should:

• use type="text" so that no browser clear icon renders (should just involve removing instances of type="search" since SearchInput defaults to text)
• ensure any examples using SearchInput have the PF clear button rendered when applicable. See search input basic for an example of this (after typing in the input).
• Ensure examples have some sort of labeling (either text or aria) that conveys it as a search input

This would probably also include deprecating/removing the type prop on SearchInput to avoid dual clear icons rendering.

[gitdallas]

@thatblindgeye @nicolethoen - i'm also seeing that we use type="search" in other places, like directly on an input element within the Select filterBox and on TextInput components in the PrimaryDetail demos.

should anything be done about these?

[gitdallas]

also, on the last point... should i deprecate/remove the type prop?

  /** Type of the input */
  type?:
    | 'text'
    | 'date'
    | 'datetime-local'
    | 'email'
    | 'month'
    | 'number'
    | 'password'
    | 'search'
    | 'tel'
    | 'time'
    | 'url';

[thatblindgeye]

I feel like it'd make sent to update those other uses of type="search" to type="text", and also adding an aria-label="Search" (or "Filter" or whatever action is most applicable) if there isn't already one on the input element/component.

@nicolethoen would we be able to just remove the type prop from SearchInput, or should we deprecate it and add a disclaimer that "text should be used"? Most of the values for the prop may not be relevant for the component.

[nicolethoen]

I think we determined that the difference between type search and text is really just the presence (or not) of the close button in the input. So as long as it still has a close button that is added by patternfly and the screen reader still calls the input a search in the examples, then I see no reason why someone would want to set it back to being type search. it's still a breaking change in case people are looking for type search in any of their css or test selectors, so we'd need to warn the users of the change via a code mod.