When you consider how integral search elements to user interfaces and user experience more general, you might be surprised to learn they were only introduced to the HTML spec in 2023.
If you’ve ever built a search bar in HTML, it could well have looked a little like this:
<div class="search-container" role="search">
<form action="/search" method="get">
<label for="q">Search</label>
<input type="text" id="q" name="q" placeholder="Search..." />
<button type="submit">Go</button>
</form>
</div>
It’s not terrible, but there’s a lot going on. The role="search" is there to communicate to screen readers what it’s for, the wrapping <div> is largely redundant but used for styling with a class or ID, and if you forget the ARIA role, your search widget is just an anonymous blob in the accessibility tree.
Handle all of these issues, and make your HTML more semantic with the <search> element, so let’s take a closer look at it…
The <search> Element
The <search> element is a semantic HTML element designed specifically for search and filtering.
It maps implicitly to the search ARIA landmark role, so screen reader users can navigate to it just like they would a <nav> or <main>, with means the role attribute isn’t needed.
With this in mind, we would be able to replace that redundant <div> right away:
<search>
<form action="/search" method="get">
<label for="q">Search</label>
<input type="search" id="q" name="q" placeholder="Search..." />
<button type="submit">Go</button>
</form>
</search>
Beyond Global Search
The <search> elements works anywhere users are searching or filtering content, not just a global search bar. A filter panel on a product listings page, a “find in this list” input, a location search in a booking flow, all of these are appropriate uses for the element, like so:
<search aria-label="Filter products">
<label for="filter">Filter by name</label>
<input type="search" id="filter" name="filter" />
</search>
If you’ve got more than one <search> on a page, add an aria-label to distinguish them — just like you would with multiple <nav> elements.
Input Type Matters
You’ll also notice that inside of <search>, we’re using <input type="search"> rather than <input type="text">, which will render a clear (×) button once the user starts typing and assistive tools that specifically look for search inputs will identify it correctly.
<!-- just a text field -->
<input type="text" name="q" />
<!-- tells the browser this is a search input -->
<input type="search" name="q" />
We always enjoy sharing tips you can act on right away, and this one couldn’t be simpler. As you can see, in addition to making your HTML a little more semantic, using <search> means your ARIA roles are handled for you, and assistive technology users get a proper landmark to navigate to.
As always, let us know if you’ve got some tips and tricks you’d like to share and subscribe to the Dev Digest for more.