Coop Design System
Components

Search field

An input optimised for filtering or finding items within a dataset, page, or site.

Preview

When to use

Use a search field when users need to filter or find items within a dataset, page, or site. Appropriate for:

  • Site-wide search in headers or navigation.
  • Filtering content within a list, table, or catalogue.
  • Any context where the primary action is finding something specific.

When not to use

  • Don't use a search field when users are entering free-form data for submission in a form — use Input instead.
  • Avoid search fields for short, static lists where all options are visible — Select or Listbox may be a better fit.

Behaviour

As the user types, results can update dynamically (live filtering) or wait for form submission (submittable variant).

  • Submittable: the field includes a search button. The user triggers the search explicitly by pressing Enter or clicking the button.
  • Non-submittable: no button. Results respond immediately as the user types, useful for inline filtering.

Clearing the field (when filled) should reset results to the default state.

Anatomy

  • Search icon — left-aligned inside the field, indicates the field's purpose. Not interactive.
  • Input area — where the user types the query.
  • Placeholder text — a short prompt, e.g., "Search…", that disappears when the user starts typing.
  • Clear button — appears when the field is filled; clears the current query.
  • Submit button (Submittable variant only) — triggers the search action.

Variants

Submittable Includes a visible search/submit button. Use when the search is query-driven and results are loaded on demand (e.g., a search results page).

Non-submittable No submit button. Use for live/inline filtering where results update as the user types.

Both variants support Filled (has query text) and Empty states.

States

  • Default (empty) — placeholder text visible; clear button hidden.
  • Filled — query text entered; clear button visible.
  • Hover — field highlights on cursor hover.
  • Focus — focus ring visible; field is active for keyboard input.
  • Read only — current query is shown but cannot be edited. The submit button (if present) is also inactive.
  • Disabled — field is non-interactive and visually reduced.

Placement & layout

Place the search field at a consistent, predictable location for the context:

  • Site-wide search: in the header, right-aligned or centred depending on the layout.
  • Inline filtering: above the list or table it controls, full-width or constrained to match the content area.

Ensure the search field is wide enough to accommodate typical queries without truncation. On mobile, it should expand to fill the available width.

Accessibility

  • The input must have an accessible label. Use a visible <label> or aria-label="Search".
  • Include role="search" on the wrapping element (or use <search>) to create a search landmark for screen reader navigation.
  • The submit button needs an accessible label (e.g., aria-label="Submit search").
  • The clear button needs an accessible label (e.g., aria-label="Clear search").
  • Live filtering results should use a role="status" or aria-live="polite" region to announce result counts (e.g., "12 results found").
  • Keyboard: Tab to focus, type to enter query, Enter to submit (Submittable), Escape to clear.
  • Input — for general text entry and form fields.
  • Select — for choosing from a predefined list.
  • Listbox — for displaying selectable results within a list.

On this page