<search> in HTML: the landmark that sends screen readers straight to search

On a site with a lot of content, a screen reader often offers to jump straight from one important region to another: the main menu, the content, the footer. For a long time, the search area was not one of those regions, it was just another form, only discoverable by tabbing through the page field by field.

The <search> element fixes that gap: it turns the search, or filtering, area into a full navigation landmark, on the same footing as the menu or the main content.

Definition

<search> marks a portion of a page whose role is to search or filter content: a global search field, but also a set of filters on a results page or a catalogue. It is a recent addition to the standard, and it natively carries the search landmark role for assistive technologies, with nothing extra to add.

Syntax and attributes

<search> has no attribute of its own: it accepts the global attributes, plus, when several search areas coexist on the same page, aria-label, to give each one a distinct name in the landmark list. Without it, two identically named search regions become hard to tell apart with a keyboard.

<search>
  <form action="/search">
    <label for="q">Search for a course</label>
    <input type="search" id="q" name="q" />
    <button type="submit">Search</button>
  </form>
</search>

Difference from a plain form

A <form> describes an intent to submit data, whatever its content: signing in, registering, searching, paying. A screen reader only surfaces it in the list of forms, a list many users never check first. <search> adds a layer on top: it places the same area in the list of navigation landmarks, the one most screen reader users check first to understand how a page is organised. Before this element existed, the only way to get that result was adding role="search" to a <div> or a <form>: it worked, but only as long as nobody forgot the attribute. <search> makes that behaviour native, without depending on an ARIA attribute added by hand.

Not just a search box

The standard describes <search> more broadly than a single text field: it also fits a block of filters on a results page, for instance a set of checkboxes narrowing a course catalogue by topic and level. What these uses have in common is the same: the user is searching or filtering content located elsewhere on the page, and needs quick access to that block without confusing it with the rest of the navigation. On a results page, this landmark is often followed by an <hgroup> announcing how many results were found, alongside a subtitle summarising the active filters. Some instant-suggestion interfaces even generate their results from a <template>, cloned in JavaScript on every keystroke.

Best practices for placement

A navigation landmark only has value if a user can find it quickly in the list their screen reader offers. It is therefore best to place <search> early in the page, for instance in the header or right before the main content, rather than tucking it away at the bottom of a secondary sidebar. It does not need to power instant results or rely on JavaScript either: a plain, classic search form with no special interactivity deserves to be wrapped in this landmark just as much.

No, <search> comes on top of the form, not instead of it. The <form> still handles submitting the data; <search> simply wraps that area so it becomes discoverable as a full navigation landmark.

Yes, for example a global search in the site header and a block of filters on a catalogue page. In that case, it is recommended to give each one a different aria-label, so the landmark list stays understandable when navigating by keyboard.

No, this element carries no default styling at all, exactly like a navigation menu. It changes nothing about appearance: its only role is semantic, styling stays entirely up to CSS.