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

Use the contract

A reviewer searches a public incident archive by a case reference. The search element identifies the area, the label supplies the field name, and the submit button makes the action clear on physical and virtual keyboards. The server route performs the search and returns an actual results page; neither the element nor the input type implements indexing. Keep the query name stable because saved links and analytics may depend on it. If the archive contains private records, a GET query in the URL can leak through history, logs, or sharing. In that case, design a different retrieval contract with authorization rather than merely changing the markup.

<search>
  <form action="/public-incidents/search" method="get">
    <label for="incident-query">Search public incidents</label>
    <input id="incident-query" name="query" type="search" required>
    <button type="submit">Search records</button>
  </form>
</search>

Behavior and cost

The static form is small and works without a client bundle, but the result route needs an index, safe query handling, useful empty-state copy, and pagination once results grow. Search latency depends on that service, not on the HTML input. Test an empty query, punctuation, a case reference with spaces, zero results, and direct navigation to a result URL. An accessible landmark does not compensate for a dead endpoint; the shown path is illustrative until the archive search exists.

Common Mistakes

• Do not use the search element as if it executes a search.
• Do not hide a sensitive query in a shareable GET URL.
• Do not replace the visible submit button with a keyboard hint alone.

Connected lessons

• HTML search element: mark a search interface by purpose
• 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 mark: identify relevant text without calling it a warning.