What the HTML search Element Is For
<search> is not a new kind of input. It is a semantic wrapper for the part of a page used to search or filter content.
That sounds modest because it is. The form continues to do the work; <search> gives the region a name the browser and assistive technology can understand.
Wrap the existing form
<search>
<form action="/search/">
<label for="q">Search</label>
<input id="q" name="q" type="search">
<button>Search</button>
</form>
</search>
The wrapper exposes a search landmark. A screen-reader user can navigate to landmarks without moving through every element before them.
A <div class="search"> can look identical, but it does not carry that meaning by itself. You could add role="search" to an older container; the native element is the more direct spelling when your supported browsers and tools handle it.
Filtering belongs here too
The region does not need a text field. Controls that find or filter a set of results can fit:
<search>
<form>
<label>
Category
<select name="category">
...
</select>
</label>
<label>
Price
<select name="price">
...
</select>
</label>
<button>Apply filters</button>
</form>
</search>
A contact, checkout, or login form is not search. Semantics become less useful when every form receives the same landmark.
The form is still necessary
<search> provides structure, not submission behaviour:
<search>
<input type="search">
</search>
That input will not navigate to a results page unless JavaScript handles it. For a normal website, keep the <form action="…"> so search works without a script.
Visible labels remain the best default. A compact header can use an accessible name when the design truly has no room, but the wrapper does not label the field for you.
Styling is ordinary
search {
display: block;
}
search form {
display: flex;
gap: 0.5rem;
}
I would use <search> around a distinct search or filter region and otherwise leave the markup alone. It will not produce a dramatic screenshot. Quietly making the page easier to navigate is the whole point.
Related articles
- When a Control Needs aria-label
Use aria-label for genuinely unlabelled controls while keeping visible text and native elements as the first choice.
- When CSS Layout Order Stops Matching the HTML
Keep Grid and Flexbox layouts aligned with the HTML order so keyboard focus and screen reader reading do not jump around the page.
- What You Get With a Real HTML Button
A native HTML button includes keyboard, focus, form, disabled, and accessibility behaviour that a clickable div must rebuild.