<search>: A Native Landmark For Search And Filter UI

<search> carries an implicit ARIA role of "search" the moment it's used — the same landmark role developers previously had to remember to add manually via role="search" on a <div> or <form>. Screen readers expose a dedicated landmark-navigation mechanism (typically a keyboard shortcut cycling through regions like <header>, <nav>, <main>, <footer>, and now <search>), letting users jump directly to a page's search functionality without linearly tabbing or reading through everything preceding it.

This mirrors exactly how <nav> replaced <div role="navigation"> and <main> replaced <div role="main"> — native HTML semantics that make correct accessibility the path of least resistance instead of an opt-in detail easy to forget.

It's important not to conflate <search> with <form> — they solve different problems and are meant to be used together, not as alternatives. <form> still owns submission behavior: action, method, validation, and the actual HTTP request or client-side handling when submitted. <search> owns landmark semantics: marking the *region* as a search area for assistive technology navigation, regardless of how many controls or forms live inside it.

The correct, common pattern nests a real <form> (or, for a client-side-only instant-filter widget with no traditional submission, a set of related controls without necessarily needing a <form> at all) inside <search> — <search> around, <form> doing the actual submission work within.

<search> isn't limited to a single literal <input type="search"> — it applies to any self-contained group of controls whose collective purpose is searching or filtering content: a global header search box, a product-filtering sidebar combining a text input with category and price-range controls, or an in-page 'find in table' widget all qualify equally.

When a page legitimately has more than one <search> region — a global site search plus a page-specific filter panel, for example — each needs its own distinguishing aria-label, exactly the established convention for multiple <nav> landmarks on a single page. Without distinct labels, a screen reader user navigating by landmark hears two unlabeled 'search' regions with no way to tell which is which before entering it.

A Landmark Screen Readers Can Jump Straight To. Screen reader users navigate pages by landmark — jumping directly to <nav>, <main>, or a search region — the way a sighted user's eye jumps to a familiar magnifying-glass icon. Until recently, HTML had no native element for that last one; <search> closes the gap.

<search> Is A Native Landmark With Implicit role="search". The <search> element wraps a search-related group of controls — typically a form containing at least a text input — and carries an implicit ARIA role of "search", giving assistive technology users direct landmark-navigation access to it without any explicit role attribute.

The <search> Element's Implicit Role. What ARIA role does <search> carry implicitly, without needing an explicit role attribute?

• →role="search"
• →role="form"
• →It has no implicit role at all

It's A Grouping Wrapper, Not A Replacement For <form>. <search> doesn't replace or absorb the <form> element — the correct pattern nests a real <form> (or a set of search-related controls) inside <search>, since <search> establishes the landmark region while <form> retains its own distinct submission semantics.

Nesting <search> And <form>. What is the correct relationship between <search> and <form> when building a search UI?

• →<search> wraps a <form> (or search controls); it doesn't replace <form>
• →<search> fully replaces the need for a <form> element
• →<form> should wrap <search>, the reverse order

Direct Landmark Navigation For Screen Reader Users. Screen readers expose a landmark-navigation shortcut (commonly cycling through regions with a dedicated key) letting users jump straight between <header>, <nav>, <main>, and now <search> — without <search>, users had to either tab through the entire page or rely on the site author correctly adding role="search" manually, which was frequently forgotten.

The Real Accessibility Payoff. Before <search> existed, how did most sites (correctly) mark up a search region for landmark navigation?

• →Manually adding role="search" to a <div> or <form> — easy to forget
• →There was no way to achieve this at all before <search>
• →A dedicated aria-search="true" attribute

Appropriate Uses: Site Search, Filter UIs, And In-Page Search Widgets. <search> suits any self-contained group of controls whose purpose is searching or filtering content — a global site-search widget in the header, a product-filtering sidebar on an e-commerce listing page, or an in-page 'find in table' control — not just a single literal <input type="search">.

When <search> Applies. Does a product-filtering sidebar (search box plus category/price filters) on an e-commerce page qualify for <search>?

• →Yes — it's a self-contained group of controls for searching/filtering content
• →No — <search> only applies to a single, literal <input type="search">
• →No — <search> can only be used in the page header

Give Multiple <search> Regions Distinct Accessible Names. If a page has more than one <search> region — a global header search and a page-specific in-content filter, for instance — each needs a distinct aria-label so landmark navigation announces which is which, exactly the same requirement that already applies to multiple <nav> elements on one page.

Multiple <search> Regions. A page has both a global header search and a separate in-page result-filtering widget. What should each <search> element have?

• →A distinct aria-label on each, so landmark navigation can announce which is which
• →Nothing extra — <search> elements are automatically distinguished
• →A page can only legally contain one <search> element

<search> Element Mastered. You now know how to mark up search and filter UIs with the <search> landmark element, why it wraps rather than replaces <form>, and how to label multiple search regions on the same page distinctly for landmark navigation.

Wrap A Search Form Semantically. The <search> landmark element wraps a form whose purpose is searching the page or site.