<search>

Das <search>-Element ist ein semantisches Sectioning-Element, das automatisch die implizite ARIA-Rolle search erhält. Damit erkennen Screenreader und andere assistive Technologien sofort, dass es sich um einen Suchbereich handelt. Nutzer können gezielt dorthin navigieren, ohne sich durch die restliche Seite arbeiten zu müssen.

Ein paar wichtige Punkte zum Verständnis:

Kein Formular-Ersatz: Das <search>-Element ist kein Ersatz für <form>. Es ist ein semantischer Container, der einen Suchbereich markiert. Innerhalb von <search> kannst du ein <form> verwenden, musst es aber nicht. Wenn du eine clientseitige Suche mit JavaScript baust, kann <search> auch ohne <form> stehen.

Ersetzt div role=“search”: Vor der Einführung von <search> war <div role="search"> die empfohlene Methode, um Suchbereiche semantisch auszuzeichnen. Das neue Element macht genau dasselbe, nur eleganter und direkt im HTML. Bestehenden Code mit role="search" kannst du nach und nach durch <search> ersetzen.

Mehrere pro Seite erlaubt: Eine Seite kann mehrere <search>-Elemente enthalten. Ein typisches Szenario: Eine globale Suchleiste im Header und ein Filterbereich in der Sidebar. In diesem Fall solltest du jedes <search> mit einem aria-label versehen, um die Bereiche voneinander unterscheidbar zu machen.

Nicht nur für Volltextsuche: Das Element beschränkt sich nicht auf klassische Suchformulare. Auch Produktfilter, Sortieroptionen, Datumsfilter oder andere Mechanismen, mit denen Nutzer Inhalte eingrenzen, gehören semantisch in ein <search>-Element.

Das <search>-Element hat die implizite ARIA-Rolle search. Das bedeutet, dass Screenreader den Bereich automatisch als Suchbereich erkennen und ankündigen. Nutzer können mit Landmark-Navigation direkt dorthin springen, ohne durch die restliche Seite navigieren zu müssen. Du musst kein zusätzliches role="search" setzen — das wäre sogar redundant.

Wenn du mehrere <search>-Elemente auf einer Seite verwendest, solltest du jedes mit einem eindeutigen aria-label versehen. Ohne Label würde ein Screenreader bei jedem Bereich nur “Suche” ankündigen, und Nutzer könnten nicht unterscheiden, ob es sich um die globale Seitensuche oder einen lokalen Produktfilter handelt.

<search aria-label="Seitensuche">
  <!-- Globale Suche im Header -->
</search>

<search aria-label="Produktfilter">
  <!-- Filterbereich in der Sidebar -->
</search>

Innerhalb des <search>-Elements solltest du darauf achten, dass Formular-Elemente korrekt mit Labels verknüpft sind. Ein <input type="search"> braucht entweder ein <label>, ein aria-label oder einen sichtbaren Platzhaltertext, der die Funktion beschreibt. Denk daran, dass placeholder allein kein Label-Ersatz ist, da er verschwindet, sobald der Nutzer tippt.

search statt form verwenden: Ein häufiges Missverständnis ist, dass <search> das <form>-Element ersetzt. Das ist nicht der Fall. <search> ist ein semantischer Container, der einen Suchbereich markiert. Das eigentliche Suchformular mit action, method und der Submit-Logik steckt weiterhin in einem <form> innerhalb von <search>. Ohne <form> funktioniert kein nativer Formular-Submit.

search für nicht-suchbezogene Inhalte: Das <search>-Element ist ausschließlich für Bereiche gedacht, die der Suche oder Filterung von Inhalten dienen. Ein Kontaktformular, ein Login-Formular oder ein Newsletter-Anmeldeformular gehören nicht in ein <search>. Verwende dafür einfach <form> ohne zusätzlichen semantischen Container.

role=“search” zusätzlich setzen: Da <search> bereits die implizite ARIA-Rolle search hat, ist ein zusätzliches role="search" auf dem Element überflüssig und redundant. Screenreader ignorieren das doppelte Attribut zwar, aber es bläht den Code unnötig auf.

<!-- Falsch: redundantes role -->
<search role="search">
  <form>...</form>
</search>

<!-- Richtig: search hat die Rolle bereits -->
<search>
  <form>...</form>
</search>

Nur ein einziges search pro Seite erlauben: Manche Entwickler denken, dass es nur ein <search>-Element pro Seite geben darf. Das stimmt nicht. Du kannst mehrere verwenden, zum Beispiel für die Hauptsuche im Header und einen Filterbereich in der Sidebar. Achte in dem Fall einfach auf eindeutige aria-label-Attribute.

Das <search>-Element wird von allen modernen Browsern unterstützt. In älteren Browsern wird es als generisches Inline-Element behandelt, was bedeutet, dass die Funktionalität erhalten bleibt, aber die semantische Rolle nicht an assistive Technologien kommuniziert wird.

Das search-Element wird von allen modernen Browsern unterstützt. In älteren Browsern wird es als unbekanntes Element behandelt, funktioniert aber weiterhin als Container.

• Chrome

  Komplett

• Firefox

  Komplett

• Safari

  Komplett

• Edge

  Komplett

• Opera

  Komplett

Das search-Element wird in HTML-E-Mails nicht unterstützt. E-Mail-Clients ignorieren semantische HTML5-Elemente oder entfernen sie komplett. Verwende stattdessen table- oder div-basierte Strukturen mit Inline-Styles.

• Apple Mail

  Keine

  Semantische HTML5-Elemente werden nicht unterstützt.

• Gmail

  Keine

  Gmail entfernt unbekannte HTML-Elemente.

• Outlook

  Keine

  Outlook ignoriert semantische Elemente vollständig.

• Thunderbird

  Keine

  Keine Unterstützung für das search-Element.

• Yahoo Mail

  Keine

  Unbekannte HTML-Elemente werden nicht unterstützt.