HTML search element: mark a search interface by purpose

When the element earns its place

A case archive has a site search separate from the current case's review form. Wrapping the search form in search gives the region a clear purpose without changing what the server receives. The form still needs a real action and a named query control. The input label describes the thing being searched; the button states the action. If the page contains several search regions, give each an accessible name that distinguishes its scope.

<search aria-label="Case archive search">
  <form action="/cases/search" method="get">
    <label for="case-query">Find a case by reference</label>
    <input id="case-query" name="query" type="search" required>
    <button type="submit">Search cases</button>
  </form>
</search>

Behavior boundary

The server must implement the local search route and handle missing, long, or hostile query values. Search markup does not index records, rank results, or restrict which cases a user may see.

Cost and operational limits

The element has negligible runtime cost. Search latency comes from the endpoint and its index; measure that separately from the cost of rendering one small form.

Common Mistakes

• Do not wrap every filter in a site-wide search region.
• Do not omit a label because the control has type search.
• Do not expose private cases solely because a query matches.

Connected lessons

• HTML landmarks: give navigation, main content, and page edges clear owners
• HTML forms: choose GET for retrieval and POST for a state change
• HTML labels: bind each control to a durable accessible name

Continue with HTML search form: pair a search landmark with a real GET result route.