Meta Title (69 Zeichen): Icon-Buttons, dekorative Bilder und aria-label richtig einsetzen

Meta Description (159 Zeichen): So vermeiden Sie typische Frontend-Fehler bei Icon-Buttons, dekorativen Bildern und aria-label. Mit Schnelltests, Codebeispielen und sofort nutzbaren Fixes.

Icon-Buttons, dekorative Bilder und aria-label: die häufigsten Fehler im Frontend

Viele Teams wissen grundsätzlich, dass Bilder Alternativtexte brauchen. In der Praxis scheitern sie aber an den Grenzfällen: dem reinen Icon-Button ohne sichtbaren Text, dem dekorativen SVG im CTA oder dem Produktbild, das gleichzeitig Link, Statussignal und Schmuckelement ist.

Genau hier werden alt, aria-label und aria-hidden häufig verwechselt. Das Ergebnis ist selten subtil: Screenreader lesen Button-Namen doppelt vor, Schließen-Icons bleiben unbenannt, oder dekorative Grafiken blähen die Bedienung unnötig auf.

Dieser Beitrag ergänzt den allgemeinen Leitfaden zum Schreiben guter Alternativtexte bewusst mit einem engeren Frontend-Angle: Wann braucht ein Icon-Button ein aria-label, wann genügt alt="", und wann ist aria-hidden="true" der richtige Hebel?

Der 10-Minuten-Schnelltest für Icon-Buttons und Bilder

Wenn Sie wenig Zeit haben, prüfen Sie zuerst diese fünf Stellen:

1. Header und Mobile Nav: Hamburger-Menü, Suche, Close-Button, Account-Icon
2. Cookie-Banner und Modals: Schließen-Symbol, Pfeile, Info-Icons
3. Formulare: Passwort einblenden, Fehler- oder Hilfe-Icons, Upload-Buttons
4. Karten und Listen: Favorit, Teilen, Merken, Filtern, Sortieren
5. Dekorative Bilder in Buttons oder Cards: Pfeile, Häkchen, Hintergrund-SVGs

So testen Sie ohne Spezial-Setup:

• Tabben Sie nur mit der Tastatur durch die Seite.
• Prüfen Sie, ob jeder Icon-Button einen verständlichen Zweck hat.
• Öffnen Sie DevTools und kontrollieren Sie den Accessible Name.
• Achten Sie darauf, ob dekorative Icons zusätzlich angesagt werden.
• Prüfen Sie bei <img>, ob informative Bilder ein sinnvolles alt haben und rein dekorative Bilder ein leeres alt="".

Wenn schon dieser Schnelltest scheitert, lohnt direkt der strukturierte Gegencheck mit automatischen und manuellen BFSG-Tests.

Die Grundregel: Nicht das Bild benennen, sondern die Funktion

Der häufigste Denkfehler lautet: "Da ist ein Icon, also beschreibe ich das Icon." Für die Nutzung ist aber fast nie die Form des Icons entscheidend, sondern seine Funktion.

• Eine Lupe ist nicht einfach "Lupe", sondern meist "Suche".
• Ein X ist nicht "Kreuzsymbol", sondern "Dialog schließen".
• Ein Herz ist nicht "Herz", sondern oft "Zu Favoriten hinzufügen".

Für funktionale Elemente gilt deshalb: Benennen Sie das, was der Button tut, nicht das, was das Icon zeigt.

Das ist auch der praktische Kern der W3C-Technik zu aria-label: Das Attribut liefert einen zugänglichen Namen für Objekte wie Buttons, wenn kein geeigneter sichtbarer Text vorhanden ist.

Wann aria-label bei Icon-Buttons richtig ist

Ein aria-label ist typischerweise dann richtig, wenn ein interaktives Element keinen sichtbaren Text hat und Sie ihm trotzdem einen verständlichen zugänglichen Namen geben müssen.

Typische Fälle:

• Close-Button im Modal
• Such-Button mit Lupen-Icon
• Menü-Button im Mobile Header
• Teilen-, Download- oder Bookmark-Button
• Passwort-Sichtbarkeit umschalten, wenn der Text nicht sichtbar vorhanden ist

Gutes Muster

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

Warum dieses Muster robust ist:

• Der Button bekommt den verständlichen Namen.
• Das SVG wird mit aria-hidden="true" aus der Accessibility Tree entfernt.
• focusable="false" verhindert bei älteren Browser-/SVG-Kombinationen unnötige Fokussierbarkeit.

Schlechtes Muster

<button type="button">
  <svg aria-label="Kreuz" viewBox="0 0 16 16">
    <path d="..." />
  </svg>
</button>

Das Problem: Sie benennen hier das Bildchen im Button, nicht sauber das interaktive Element selbst. Je nach Umsetzung kann der Button dadurch unklar oder inkonsistent benannt sein.

Wichtig: Wenn bereits ein sichtbarer Text existiert, ist aria-label oft nicht die beste erste Wahl. Dann sollte der sichtbare Text den zugänglichen Namen tragen, statt daneben eine zweite unsichtbare Benennung einzuführen. Das passt auch zur allgemeinen ARIA-Regel: sichtbare Labels möglichst referenzieren oder nativ nutzen, statt sie künstlich zu überschreiben. Mehr dazu finden Sie ergänzend im Beitrag zu ARIA-Fehlern und sicheren Patterns.

Wann aria-hidden="true" richtig ist und wann nicht

aria-hidden="true" ist kein Allzweck-Fix. Es entfernt ein Element und seine Kinder aus der Accessibility Tree. Das ist sinnvoll bei nicht-interaktiven, redundanten oder rein dekorativen Inhalten. Es ist falsch auf fokussierbaren oder eigenständig bedienbaren Elementen.

Sinnvolle Fälle

• dekoratives SVG im Button
• rein visuelles Status-Icon zusätzlich zu vorhandenem Klartext
• wiederholtes Symbol neben bereits vorhandenem Linktext
• Schmuckgrafik ohne Informationswert

Falsche Fälle

• auf einem Button selbst
• auf einem Link selbst
• auf einem fokussierbaren Element
• auf einem Container, in dem noch fokussierbare Kinder liegen

Typischer Fehler

<button aria-hidden="true">
  <svg viewBox="0 0 16 16"><path d="..." /></svg>
</button>

Das ist kritisch, weil der Button sichtbar und potenziell bedienbar bleibt, für Assistive Technology aber verschwindet.

Gerade bei interaktiven Komponenten sollten Sie aria-hidden deshalb nur auf dekorative Unterelemente, nicht auf das Bedienelement selbst setzen. Wenn Sie ohnehin Fokus und Tastatur prüfen, kombinieren Sie das am besten mit dem Leitfaden zur Tastaturbedienung, Fokus-Reihenfolge und Skip-Links.

Dekorative Bilder: alt="" ist meist richtiger als ARIA

Bei normalen HTML-Bildern mit <img> gilt für dekorative Bilder in der Regel eine einfache Praxisregel:

• Informativ oder funktional: sinnvolles alt
• Rein dekorativ: leeres alt=""

Genau hier entsteht oft Verwirrung. Viele Teams setzen bei dekorativen <img> reflexhaft aria-hidden="true". Das kann funktionieren, ist aber bei klassischen HTML-Bildern meist nicht die sauberste Basislösung. Der robustere Standard ist in der Regel ein leerer Alt-Text.

Beispiel für ein dekoratives Bild

<img src="divider-wave.png" alt="" />

Beispiel für ein informatives Bild

<img
  src="checkout-fehler.png"
  alt="Screenshot einer Fehlermeldung im Checkout mit hervorgehobenem Pflichtfeld"
/>

Beispiel für ein funktionales Bild in einem Link

<a href="/konto">
  <img src="logo-konto.png" alt="Zum Kundenkonto" />
</a>

Ob ein Bild dekorativ ist, entscheidet nicht das Dateiformat, sondern sein Zweck im Kontext. Derselbe Pfeil kann auf einer Seite Schmuck sein und auf einer anderen die einzige Bedeutung eines Buttons tragen.

Die häufigsten Fehler, die in Frontends immer wieder auftauchen

1) Icon-Button ohne zugänglichen Namen

Der Button sieht visuell eindeutig aus, hat aber keinen Text und kein aria-label.

Folge: Screenreader-Nutzer hören nur "Button" oder einen technischen Namen.

Sofort-Fix: aria-label direkt am Button ergänzen, dekoratives SVG mit aria-hidden="true" markieren.

2) Dekoratives Icon wird doppelt vorgelesen

Im Button steht sichtbarer Text wie "Suche", zusätzlich wird das Lupen-SVG noch als eigenes Objekt exponiert.

Folge: unnötige Redundanz, teilweise doppelte Ansage.

Sofort-Fix: Das Icon als dekorativ behandeln, also aus der Accessibility Tree nehmen.

3) aria-label überschreibt einen guten sichtbaren Text

Ein Button zeigt sichtbar "Termin buchen", trägt aber aria-label="Jetzt absenden".

Folge: sichtbare und vorgelesene Bezeichnung laufen auseinander. Das ist verwirrend, gerade für Menschen, die visuell und auditiv parallel arbeiten.

Sofort-Fix: sichtbaren Text und zugänglichen Namen angleichen. Wenn der sichtbare Text gut ist, aria-label meist entfernen.

4) Dekoratives <img> ohne leeres alt

Das Bild hat keinen Informationswert, aber entweder gar kein alt oder einen belanglosen Text wie alt="dekorativ".

Folge: Screenreader erhalten unnötigen Ballast oder Dateiinformationen.

Sofort-Fix: alt="" setzen.

5) State-Wechsel ohne aktualisierte Benennung

Ein Toggle-Button wechselt zwischen "Menü öffnen" und "Menü schließen", aber das aria-label bleibt statisch.

Folge: Die Bedienung wirkt inkonsistent.

Sofort-Fix: zugänglichen Namen und Status sauber mitdenken. Bei komplexeren Mustern zusätzlich Statusattribute und sichtbare Zustände konsistent halten.

Alt text schreiben: Drei kurze Entscheidungsfragen

Wenn im Team Unsicherheit herrscht, hilft diese Kurzlogik mehr als jede Grundsatzdebatte:

Frage 1: Ist das Element interaktiv?

• Ja: zuerst die Funktion benennen, oft über sichtbaren Text oder aria-label
• Nein: weiter zu Frage 2

Frage 2: Vermittelt das Bild Information, die im Text fehlt?

• Ja: kurzes, kontextbezogenes alt
• Nein: weiter zu Frage 3

Frage 3: Ist das Bild nur Schmuck oder Wiederholung?

• Ja: alt="" bei <img> oder dekoratives SVG aus der Accessibility Tree nehmen
• Nein: vermutlich braucht das Bild doch eine sinnvolle Alternative

Diese Logik ist auch nützlich für Design Reviews, Content QA und Component Libraries. Sie verhindert, dass Teams bei jedem Icon neu diskutieren müssen.

Alternativtexte: Beispiele aus der Praxis

Ein paar kurze Alternativtexte Beispiele helfen oft mehr als abstrakte Regeln:

• Schlecht: alt="Icon Suche"

• Besser für Button-Funktion: aria-label="Suche öffnen"

• Schlecht: alt="dekoratives Trennelement"

• Besser für dekoratives Bild: alt=""

• Schlecht: alt="Bild von einem Dashboard"

• Besser: alt="Dashboard mit Filterleiste und markierter Fehlermeldung im Exportdialog"

• Schlecht: aria-label="Mehr" bei drei verschiedenen Card-Aktionen

• Besser: aria-label="Details zum Tarif Business öffnen"

• Schlecht: sichtbarer Text "PDF herunterladen" plus aria-label="Download starten"

• Besser: sichtbaren Text als Namen nutzen, dekoratives Download-Icon verstecken

Wenn Sie häufiger in Formular- und E-Commerce-Flows arbeiten, passen diese Muster besonders gut zu den Artikeln über barrierefreie Formulare und barrierefreie Checkouts.

Definition of Done für Frontend-Teams

Bevor ein Ticket zu Icon-Buttons oder Bildern als erledigt gilt, sollten Sie diese Punkte mit Ja beantworten können:

• Hat jeder Icon-Button einen verständlichen zugänglichen Namen?
• Benennt dieser Name die Funktion, nicht bloß das Symbol?
• Sind dekorative SVGs im Button für Assistive Technology ausgeblendet?
• Haben dekorative <img> ein leeres alt=""?
• Stimmen sichtbare Bezeichnung und zugänglicher Name überein?
• Bleiben keine fokussierbaren Elemente mit aria-hidden="true" zurück?
• Wurde mindestens ein echter Tastatur- und Screenreader-Namenscheck im Browser gemacht?

Fazit

Bei Bildern und Icon-Buttons scheitert Barrierefreiheit selten an fehlendem guten Willen. Sie scheitert meist an drei Verwechslungen: Bild statt Funktion benennen, Dekoration unnötig exponieren, und aria-hidden dort einsetzen, wo eigentlich ein sauberer Name fehlt.

Die gute Nachricht: Diese Fehler lassen sich schnell beheben. Wenn Sie die kritischen Komponenten Ihrer Navigation, Modals, Formulare und Cards einmal systematisch durchgehen, reduzieren Sie mit wenig Aufwand sowohl reale Nutzungsbarrieren als auch BFSG-Risiken.

CTA: Prüfen Sie Ihre wichtigsten Seiten jetzt strukturiert auf unbenannte Buttons, fehlerhafte Alt-Texte und typische ARIA-Probleme: BFSG-Scan starten

Quellen

• MDN Web Docs, ARIA: aria-label attribute: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-label
• MDN Web Docs, ARIA: aria-hidden attribute: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden
• W3C WAI, ARIA6: Using aria-label to provide labels for objects: https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA6
• W3C WAI, Decorative Images: https://www.w3.org/WAI/tutorials/images/decorative/
• W3C WAI, Decorative Images, WCAG 3 How-To: https://www.w3.org/WAI/GL/WCAG3/2020/methods/decorative-images/

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