Input "search"

Interaction methods

The field uses type="search" and has a label explaining what will be searched.

Mouse interaction

1. Clicking the field or its associated label puts focus in the field.
2. Selecting, editing, copying, and pasting follow the field's native behavior.

Keyboard interaction

1. Tab moves focus to the field; Shift + Tab returns to the previous control.
2. Typing inserts text; arrow keys, Home, End and selection and editing commands follow the platform.
3. Enter follows the form's defined submission action; the field does not create a new line.

Gesture interaction

1. Tapping the field or label allows editing with the virtual keyboard.
2. Text selection and editing follow the platform's available gestures.

Keyboard (or gesture) interaction + screen reader

1. When navigating to the field, the reader presents its label and type, along with associated states and instructions.
2. Errors are associated with the field and explain how to correct the information; the entered value is preserved.

Submit and clear search

1. Enter submits the search when that is the defined mode; the "Search" button, when present, also submits it.
2. The "Clear search" control, when present, empties the field without submitting the form and allows further editing.
3. Communicate the result count or lack of results without moving focus unexpectedly.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing Input "search"

Keyboard navigation

1. WHEN I use the Tab key to move focus to the field
2. The focus I SEE is strongly indicated visually
3. THEN, when I type, select, or edit content using native commands
4. I SEE the field value updated
5. AND, when I use Tab or Shift + Tab, I SEE focus follow page order without getting trapped in the field

Desktop screen reader

1. WHEN I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to the field, the following happens:
   • I HEAR the field's label and purpose.
   • I HEAR that the component is a search field.
   • I HEAR the required status, instructions, and associated errors, when present.
2. THEN, when I type or edit content using native commands
3. I HEAR or perceive that I can edit the field and that its value was updated.

Mobile screen reader

1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus the field, the following happens:
   • I HEAR the field's label and purpose.
   • I HEAR that the component is a search field.
   • I HEAR the required status, instructions, and associated errors, when present.
2. THEN, when I double-tap or use the appropriate gesture to activate the field and edit its content
3. I HEAR or perceive that I can edit the field and that its value was updated.

Input validation

1. WHEN an entry is rejected by a stated validation rule
2. I SEE a message associated with the field explaining how to correct the information
3. AND, when I navigate to the field with a screen reader, I HEAR the error indication and associated guidance
4. THEN, when I edit again, I SEE the value preserved for correction

Search activation

1. WHEN I enter a term and activate search according to the defined mode
2. I SEE results or a no-results message
3. AND, when I use a screen reader, I HEAR or perceive search feedback without an unexpected focus change

Considerations

1. Use a persistent label associated with the input. A placeholder is a supplementary hint and does not replace the label.
2. Associate instructions and errors with the field, for example using aria-describedby, and set aria-invalid when there is an error.
3. Indicate required status and use required when needed. Do not communicate errors solely through color.
4. Keep focus visible and ensure adequate contrast and interaction area.
5. Define whether search happens on submission or while typing. For dynamic search, preserve focus and communicate results without announcing every key; allow clearing and handle empty results.

References

Field documentation

• MDN — input type="search" (external link, opens in a new tab)

Design System

• Carbon — Search open_in_new (external link, opens in a new tab) — Component specifically for entering search terms.
• USWDS — Search open_in_new (external link, opens in a new tab) — Field and button to activate a search.