Dekorative Bilder, Alt-Texte und Icon-Buttons: Was braucht aria-hidden, was braucht aria-label?

Illustration mit dekorativem Bild, barrierefreiem Icon-Button und markierten Attributen für alt, aria-hidden und aria-label
Illustration mit dekorativem Bild, barrierefreiem Icon-Button und markierten Attributen für alt, aria-hidden und aria-label

Dekorative Bilder, Alt-Texte und Icon-Buttons: Was braucht aria-hidden, was braucht aria-label?

Bei Bildern und Icons passieren in Audits immer wieder dieselben drei Fehler: Ein dekoratives Bild bekommt einen unnötigen Alternativtext, ein wichtiges Bild bleibt ohne sinnvollen alt-Text, und ein textloser Icon-Button wird nur über sein Symbol „beschriftet“. Das Ergebnis ist für Screenreader-Nutzende oft unerquicklich: zu viel Rauschen an der falschen Stelle und zu wenig Information dort, wo Interaktion oder Verständnis davon abhängen.

Für die Praxis hilft eine einfache Unterscheidung:

  • Dekorative Bilder brauchen in der Regel kein vorgelesenes Label, sondern ein leeres alt="".
  • Informative Bilder brauchen einen passenden alt-Text, der den Zweck oder die Information transportiert.
  • Textlose Icon-Buttons brauchen einen zugänglichen Namen, oft per aria-label, wenn kein sichtbarer Text vorhanden ist.
  • Dekorative Icons innerhalb eines Buttons brauchen oft aria-hidden="true", damit nicht das Icon statt der Funktion im Accessibility Tree landet.

Genau diese Abgrenzung ist im Cluster images-alt zentral: Wer sauber zwischen Bildinhalt, Dekoration und Interaktion trennt, behebt einen großen Teil typischer BFSG- und WCAG-Probleme mit wenigen gezielten Änderungen.

Wenn Sie zuerst den Gesamtprozess der Prüfung verstehen möchten, starten Sie mit unserem Überblick Website auf BFSG-Konformität prüfen: automatisch und manuell.

Die Kurzregel: alt beschreibt Bilder, aria-label benennt Bedienelemente

Die meisten Unsicherheiten entstehen, weil alt, aria-hidden und aria-label für ähnliche Probleme gehalten werden. Technisch erfüllen sie aber unterschiedliche Aufgaben.

alt

Das alt-Attribut gehört zu <img>-Elementen. Es beschreibt den Inhalt oder Zweck eines Bildes, wenn dieses Bild für das Verständnis relevant ist.

Beispiel:

<img src="teamfoto.jpg" alt="Das Projektteam von BFSG Webcheck beim Accessibility-Workshop" />

aria-label

aria-label gibt einem Element einen zugänglichen Namen, wenn kein sichtbarer oder referenzierbarer Text vorhanden ist. Typischer Einsatz: textlose Buttons mit SVG-Icon.

<button type="button" aria-label="Suche öffnen">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
</button>

aria-hidden="true"

aria-hidden="true" entfernt ein Element aus dem Accessibility Tree. Das ist nützlich bei rein dekorativen, redundanten oder störenden Inhalten, aber riskant bei allem, was fokussierbar oder inhaltlich relevant ist.

<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>

Die wichtigste Denkregel lautet deshalb:

  • Brauchen Nutzende eine Bildbeschreibung?alt
  • Brauchen Nutzende einen verständlichen Namen für einen Button oder Link?aria-label oder sichtbarer Text
  • Soll ein dekoratives Icon oder redundanter Inhalt gar nicht vorgelesen werden?aria-hidden="true"

Quick-Test: So entscheiden Sie in 30 Sekunden pro Element

Gehen Sie jedes Bild oder Icon mit diesen vier Fragen durch:

  1. Ist das Element ein echtes Bild mit Informationswert? Dann braucht es einen sinnvollen alt-Text.
  2. Ist es nur Schmuck oder Layout? Dann meist alt="" statt beschreibendem Text.
  3. Ist es Teil eines interaktiven Elements ohne sichtbaren Text? Dann braucht der Button oder Link einen zugänglichen Namen, häufig per aria-label.
  4. Ist das Icon innerhalb eines Buttons nur dekorativ, weil der Button bereits beschriftet ist? Dann kann das Icon aria-hidden="true" bekommen.

Wenn Sie bei einem Element weder klar sagen können, warum es vorgelesen werden soll, noch warum es ignoriert werden darf, steckt meist ein Modellierungsfehler im UI.

Dekorative Bilder: Wann alt="" reicht – und wann aria-hidden überflüssig ist

Das Keyword „dekorative bilder aria hidden“ führt oft in die falsche Richtung. Für klassische <img>-Elemente ist bei rein dekorativen Bildern in der Regel ein leeres alt-Attribut die richtige Lösung – nicht ein beschreibender Alt-Text und oft auch nicht zusätzlich aria-hidden.

Typische dekorative Bilder

Dazu zählen zum Beispiel:

  • Trennlinien, Muster, Hintergründe
  • atmosphärische Stockfotos ohne inhaltlichen Mehrwert
  • wiederholte Teaserbilder, wenn die Information bereits direkt daneben als Text steht
  • rein dekorative Illustrationen in Cards oder Hero-Bereichen

Sauberer Code:

<img src="deko-welle.png" alt="" />

Warum das richtig ist:

  • Screenreader überspringen das Bild.
  • Es entsteht kein unnötiges Rauschen wie „blaue Welle“ oder „dekorative Grafik“.
  • Das Element bleibt technisch korrekt ausgezeichnet.

Wann aria-hidden zusätzlich sinnvoll sein kann

Bei dekorativen SVGs, Icons oder Wrapper-Elementen ist aria-hidden="true" oft sinnvoll, damit sie nicht versehentlich Teil des zugänglichen Namens werden.

<span class="card-icon" aria-hidden="true">
  <svg viewBox="0 0 24 24">...</svg>
</span>

Für ein normales dekoratives <img> gilt aber meist: alt="" genügt. Zusätzliche ARIA-Attribute machen den Code eher komplizierter als besser.

Informative Bilder: So schreiben Sie gute Alt-Texte

Sobald ein Bild Information transportiert, braucht es einen inhaltlich passenden Alternativtext. Genau hier suchen viele Teams nach „alt text schreiben“ oder „alternativtexte beispiele“ – und verfallen dann in zwei Extreme: zu knapp oder zu lang.

Gute Alt-Texte orientieren sich am Zweck

Ein Alt-Text soll nicht jedes Pixel beschreiben. Er soll die Information wiedergeben, die das Bild im Seitenkontext liefert.

Schwaches Beispiel:

<img src="checkout-fehler.png" alt="Screenshot" />

Besser:

<img src="checkout-fehler.png" alt="Checkout-Formular mit drei markierten Pflichtfeldfehlern und gut sichtbaren Fehlermeldungen" />

Vier Regeln für gute Alternativtexte

  1. Beschreiben Sie die relevante Information, nicht das Dateiformat.
  2. Schreiben Sie kontextbezogen, nicht generisch.
  3. Vermeiden Sie Floskeln wie „Bild von“ oder „Grafik zeigt“, wenn sie keinen Mehrwert liefern.
  4. Halten Sie den Text so kurz wie möglich und so konkret wie nötig.

Alternativtexte: Beispiele aus der Praxis

| Bildtyp | Schlecht | Besser | | --- | --- | --- | | Teamfoto | Team | Accessibility-Team im Workshop zur Tastaturbedienung einer Website | | Diagramm | Balkendiagramm | Balkendiagramm zeigt Anstieg der abgeschlossenen Formularanfragen von Januar bis März | | Produktbild | Schuh | Schwarzer Laufschuh Modell X mit weißer Sohle in Seitenansicht | | Screenshot | Website | Startseite mit sichtbarem Skip-Link, Fokusrahmen und kontrastreichem CTA-Button |

Bei komplexen Grafiken oder Diagrammen reicht ein kurzer Alt-Text allein oft nicht. Dann sollte der Alt-Text knapp einordnen, während die eigentliche Detailerklärung im Fließtext oder direkt unter der Grafik steht.

Vertiefend dazu passt unser Ratgeber Gute Alt-Texte schreiben: SEO & Barrierefreiheit.

Icon-Buttons: Wann aria-label die richtige Lösung ist

Das Keyword „icon button aria label“ zielt auf einen anderen Fall: Nicht auf Bildbeschreibung, sondern auf Benennung eines Bedienelements.

Ein Button mit Lupe, X, Herz oder Hamburger-Menü ist nicht deshalb verständlich, weil das Icon im Design-System etabliert ist. Für assistive Technologien braucht der Button einen Accessible Name, der die Aktion beschreibt.

Typischer korrekter Fall

<button type="button" aria-label="Dialog schließen">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
</button>

Hier ist aria-label passend, weil:

  • der Button keinen sichtbaren Text enthält,
  • das Icon allein keine verlässliche Beschriftung ist,
  • der Screenreader eine klare Aktion ansagen kann.

Häufige Fehlbenennungen

Schlecht:

<button aria-label="X">...</button>
<button aria-label="Lupe">...</button>
<button aria-label="Hamburger">...</button>

Besser:

<button aria-label="Dialog schließen">...</button>
<button aria-label="Suche öffnen">...</button>
<button aria-label="Hauptmenü öffnen">...</button>

Die Regel ist simpel: Beschriften Sie die Funktion, nicht das Symbol.

Wann sichtbarer Text besser ist als aria-label

aria-label ist praktisch, aber nicht immer die beste erste Wahl. Wenn sichtbarer Text möglich ist, ist sichtbarer Text meist robuster.

<button type="button">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
  <span>Suche</span>
</button>

Das ist oft besser, weil:

  • sichtbare und assistive Beschriftung automatisch zusammenpassen,
  • Übersetzung und QA einfacher werden,
  • weniger ARIA weniger Fehler erzeugt.

Wenn bereits sichtbarer Text außerhalb des Buttons vorhanden ist, kann aria-labelledby statt aria-label die sauberere Lösung sein. aria-label ist vor allem dann stark, wenn kein sichtbarer Text existiert, auf den Sie verweisen können.

Für angrenzende Bedienprobleme im UI hilft ergänzend auch unser Beitrag Tastaturbedienung testen: Fokus, Tab-Reihenfolge & Skip-Links.

Der häufigste Denkfehler: aria-hidden und aria-label am falschen Element

Viele Accessibility-Probleme entstehen nicht, weil Teams die Attribute gar nicht kennen, sondern weil sie sie auf das falsche Element anwenden.

Fehler 1: aria-hidden="true" auf dem Button

<button aria-hidden="true">
  <svg viewBox="0 0 24 24">...</svg>
</button>

Das ist kritisch, weil der ganze Button aus dem Accessibility Tree verschwindet. Ein interaktives Element darf nicht einfach für Screenreader unsichtbar gemacht werden.

Fehler 2: aria-label auf dem SVG statt auf dem Button

<button>
  <svg aria-label="Suche öffnen" viewBox="0 0 24 24">...</svg>
</button>

Auch das ist oft instabil. Der zugängliche Name soll vom interaktiven Element kommen – also vom Button oder Link, nicht vom dekorativen Icon.

Fehler 3: Bild mit echtem Informationswert wird versteckt

<img src="warnhinweis.png" alt="" aria-hidden="true" />

Wenn das Bild für das Verständnis wichtig ist, verlieren Nutzer damit die Information komplett. In solchen Fällen braucht das Bild einen sinnvollen alt-Text statt Verstecken.

Ein praktischer Entscheidungsbaum für Teams

Wenn Sie Design, Content und Entwicklung zusammenbringen wollen, funktioniert diese Reihenfolge zuverlässig:

1. Ist das Element interaktiv?

  • Ja → Button oder Link braucht einen zugänglichen Namen.
  • Kein sichtbarer Text vorhandenaria-label prüfen.
  • Icon im Button nur Deko → Icon kann aria-hidden="true" bekommen.

2. Ist das Element ein nicht-interaktives Bild?

  • Informativalt-Text schreiben.
  • Dekorativalt="".

3. Ist das Element sichtbar, aber für Screenreader redundant?

  • Dann kann aria-hidden="true" sinnvoll sein – aber nur, wenn keine Funktion oder relevante Information verloren geht.

Gerade bei Content- und CMS-Teams spart dieser einfache Entscheidungsbaum viele Abstimmungsschleifen zwischen Redaktion, Design und Frontend.

Die 80/20-Priorisierung für BFSG und WCAG

Wenn Sie nicht alles auf einmal anfassen wollen, priorisieren Sie in dieser Reihenfolge:

  1. Header und Navigation: Suche, Menü, Schließen-Buttons
  2. Dialoge und Overlays: Close-Icons, Filter, Drawer, Cookie-Banner
  3. Content-Bilder mit SEO- oder Informationsfunktion: fehlende oder schlechte Alt-Texte
  4. Dekorative Teaser- und Hero-Bilder: unnötige Alt-Texte bereinigen
  5. Design-System-Komponenten: Button-, Card- und Icon-Patterns zentral fixen

Das ist meist effizienter, als jede Seite einzeln zu reparieren. Wenn Ihr Menü oder Overlay bereits in der Komponente korrekt gebaut ist, profitieren viele Templates gleichzeitig. Für angrenzende Probleme in Overlays und UI-Fehlmustern helfen auch diese Beiträge:

Fazit: Erst den Zweck klären, dann das richtige Attribut wählen

Die Frage „Was braucht aria-hidden, was braucht aria-label?“ lässt sich in der Praxis erstaunlich klar beantworten, wenn Sie zuerst den Zweck des Elements bestimmen:

  • Dekoratives Bild? → meist alt=""
  • Informatives Bild? → sinnvoller alt-Text
  • Textloser Icon-Button? → zugänglicher Name, oft per aria-label
  • Dekoratives Icon im bereits benannten Button?aria-hidden="true"

Die häufigsten Fehler entstehen, wenn Teams Bildbeschreibung, Dekoration und Interaktion vermischen. Genau das sollten Sie vermeiden. Dann werden Screenreader-Ausgaben kürzer, präziser und verständlicher – und Ihre Oberfläche wird nicht nur normnäher, sondern auch in echten Nutzungssituationen besser.

CTA: Ihre Bilder, Icons und Buttons schnell prüfen

Wenn Sie wissen möchten, ob Ihre Website bereits typische Probleme mit Alternativtexten, dekorativen Bildern, Icon-Buttons und anderen BFSG-relevanten Mustern enthält, starten Sie mit einem strukturierten Schnellcheck.

Jetzt BFSG-Scan starten

Quellen

Hinweis: Dieser Artikel stellt keine Rechtsberatung dar, sondern dient der allgemeinen Information.

BFSG Check
Schnell prüfen, ob Ihre Website typische Barrieren hat – und was zuerst zu fixen ist (technisch, keine Rechtsberatung).