A new semantic element has landed on the HTML standard <search>. It represents a section of the document that is used to search or filter. It should contain form controls (like text inputs, dropdowns, buttons, etc.), and the scope of the search/filtering can be anything: from the same document to the whole Internet.

How it works

Before the <search> element, we could add a role="search" to the <form> tag to indicate that the form was for searching:

<form role="search" method="get" action="/search">
  <input type="search" name="search-text" />
  <button>Search</button>
</form>

With the new addition, we could use the <search> tag to wrap the form:

<search>
  <form method="get" action="/search">
    <input type="search" name="search-text" />
    <button>Search</button>
  </form>
</search>

Unfortunately, as <search> is new to the standard, it may be a while before all the browsers, screen readers, and other tools catch up. In the meantime, we could use a hack specifying the ARIA role it already has natively (similar to what happened to <nav>.) It will be redundant in the future, but it may do the trick to prepare our code for when browsers offer support for the new tag:

<search role="search">
   ...
</search>

This may seem counterintuitive: we are removing the role="search" but we are wrapping everything with a <search>. Overall, it is more text/code (three more characters only) and more nesting (one more level). This shouldn't be a problem, but I'm sure we'll see some developers complain about it.

Note: while we don't need a <form> tag to create a search component, it is interesting (and even necessary) to have one, so the search would work even without JavaScript, or following a progressive enhancement strategy.

Another critical thing to note is that a search region doesn't have to be a text input with a button for searching on the website or online. We can use <search> for filtering results or table rows. Its utility goes beyond just text inputs and search boxes:

<search>
  <h2>Filter results</h2>

  <form>
    <label for="cartype">Car type</label>
    <select id="cartype">
      <option value="coupe">Coupe</option>
      <option value="sedan">Sedan</option>
    </select>

    <label for="electric">Electric?</label>
    <input type="checkbox" id="electric" />
  </form>
</search>

Opinion

Having an element to identify search regions is nice. As Scott O'Hara specifies in this article, it was the only ARIA landmark role that didn't have a semantic equivalent in HTML until now:

• banner → <header>

• complementary → <aside>

• contentinfo → <footer>

• form → <form>

• main → <main>

• navigation → <nav>

• region → <section> (with an accessible name)

• search → ???

With <search> to identify a section that should have the "search" role, we'd have all the ARIA landmark roles covered with some semantic HTML element. This is great: it will improve accessibility (although, as stated above, it will take a while before all browsers catch up), and it expands the semantics of the language.

...but, from a programmer's perspective, it feels like it falls short or doesn't add much to the existing implementation. Other semantic elements could boost accessibility and simplify how we code specific components. For example, something like <tabpanel> and <tab> would have been considerably more compelling and valuable, in my honest opinion.

That doesn't take away any of its importance. All improvements –even the little ones– are welcome. And that will be the case for <search>. An excellent new addition to the HTML family.

More information

• HTML Living Standard: The search element.

• The search element, by Scott O'Hara.