Text-Alternativen für Icon-only-Buttons richtig umsetzen

1. Das Problem: Icon-only-Buttons ohne sichtbaren Text

Ein Button, der ausschließlich aus einem SVG-Icon besteht, etwa einem Warenkorb-Symbol oder einer Lupe, hat aus Sicht des Accessibility Tree standardmäßig keinen zugänglichen Namen, sofern das Icon nicht selbst über eingebettetes, sichtbares Text-Element verfügt. Ein Screenreader kündigt einen solchen Button dann lediglich als Schaltfläche an, ohne jede Information darüber, welche Funktion sich dahinter verbirgt, was die Bedienung für blinde Nutzer faktisch zu einem Ratespiel macht.

Das Problem betrifft ausschließlich die programmatische Ebene, nicht die visuelle: Sehende Nutzer erkennen die Bedeutung eines Warenkorb-Icons meist zuverlässig, da es sich um eine weitgehend standardisierte visuelle Konvention handelt. Genau diese implizite, rein visuelle Konvention überträgt sich aber nicht automatisch in einen programmatisch zugänglichen Namen, weshalb eine explizite Textalternative technisch nachgerüstet werden muss.

2. Visually-hidden-Text-Pattern: die robusteste Lösung

Das visually-hidden-Text-Pattern platziert echten, sichtbaren Text im DOM, versteckt ihn aber ausschließlich visuell über eine CSS-Klasse, die den Text aus dem Layout entfernt, ohne ihn aus dem Accessibility Tree zu löschen. Anders als display none oder visibility hidden, die ein Element auch für Screenreader unsichtbar machen, bleibt ein per Positionierung außerhalb des sichtbaren Bereichs versteckter Text vollständig vorlesbar.

Der entscheidende Vorteil dieses Patterns gegenüber aria-label liegt darin, dass der Text als echter, im DOM vorhandener Inhalt existiert und damit auch von Werkzeugen erfasst wird, die reinen ARIA-Attributinhalt nicht zuverlässig verarbeiten, etwa bestimmte Übersetzungswerkzeuge, Browser-Erweiterungen oder ältere Screenreader-Versionen. Zusätzlich lässt sich der Text bei Bedarf per JavaScript oder CSS auch wieder sichtbar machen, etwa für einen responsiven Breakpoint, an dem genug Platz für sichtbaren Text vorhanden ist.

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

3. aria-label: Vor- und Nachteile je Screenreader

aria-label setzt den zugänglichen Namen eines Elements direkt als Attributwert, ohne dass zusätzlicher, im DOM sichtbarer Text nötig ist, was das Pattern besonders knapp und einfach in der Anwendung macht. In der Praxis wird aria-label von allen relevanten Screenreadern, NVDA, JAWS und VoiceOver, zuverlässig unterstützt und ist damit für die reine Vorlesefunktion technisch gleichwertig zum visually-hidden-Text-Pattern.

Der praktische Nachteil von aria-label zeigt sich bei Werkzeugen, die nicht auf die Accessibility-API zugreifen, sondern direkt den sichtbaren oder im DOM vorhandenen Text auswerten, etwa Browser-übersetzungsfunktionen, Textsuche im Browser mit Strg F oder bestimmte Testautomatisierungs-Werkzeuge, die primär auf sichtbaren Text statt auf ARIA-Attribute zugreifen. Ein aria-label lässt sich außerdem leicht vergessen zu aktualisieren, wenn sich die Funktion eines Buttons ändert, da es keine sichtbare Spur im Markup hinterlässt, die bei einem Code-Review sofort ins Auge fällt.

4. Das title-Attribut: warum es keine verlässliche Lösung ist

Das title-Attribut wird von vielen Entwicklerinnen und Entwicklern fälschlich als einfache Textalternative für Icon-Buttons genutzt, weil es zusätzlich einen visuellen Tooltip bei Maus-Hover erzeugt. Tatsächlich ist die Unterstützung von title als zugänglicher Name in Screenreadern jedoch inkonsistent: Manche Kombinationen aus Browser und Screenreader lesen title vor, andere ignorieren es vollständig, insbesondere wenn zusätzlich ein aria-label oder sichtbarer Text vorhanden ist, der dann Vorrang erhält.

Ein weiteres praktisches Problem betrifft Tastatur- und Touch-Nutzer: Ein title-Tooltip erscheint ausschließlich bei Maus-Hover, ist also für reine Tastaturnutzer und für Touch-Geräte ohne Hover-Fähigkeit grundsätzlich unerreichbar, unabhängig von der Screenreader-Unterstützung. Das title-Attribut sollte deshalb höchstens als visuelle Zusatzinformation für Maus-Nutzer verstanden werden, niemals als alleinige, verlässliche Textalternative für den zugänglichen Namen.

5. Tooltip-Kompatibilität: sichtbaren Tooltip und programmatischen Namen kombinieren

Für Icon-Buttons, bei denen sowohl ein sehender Maus-Nutzer als auch ein Screenreader-Nutzer dieselbe Information erhalten sollen, empfiehlt sich die Kombination aus einem eigenen, per JavaScript gesteuerten Tooltip-Element und dem visually-hidden-Text-Pattern, statt sich auf das unzuverlässige title-Attribut zu verlassen. Der Tooltip liefert dabei die sichtbare Information bei Hover oder Fokus, während der zugängliche Name des Buttons unabhängig davon über den versteckten Text feststeht.

Wichtig ist, den Tooltip zusätzlich per Tastatur-Fokus einblendbar zu machen, nicht nur bei Maus-Hover, damit auch sehende Tastaturnutzer, etwa Menschen mit motorischen Einschränkungen, dieselbe visuelle Information erhalten wie Maus-Nutzer. Ein solcher Tooltip sollte zudem über role tooltip und eine Verknüpfung per aria-describedby erfolgen, nicht über aria-label, da aria-label den ohnehin vorhandenen versteckten Text sonst überschreiben oder doppeln würde.

6. Praxisbeispiel: das Warenkorb-Icon in Hyvä

In einem Hyvä-Theme besteht der Warenkorb-Button im Header meist aus einem SVG-Icon plus einem dynamisch aktualisierten Zähler für die Artikelanzahl. Der zugängliche Name muss dabei sowohl die Grundfunktion, Warenkorb öffnen, als auch die dynamische Artikelanzahl abbilden, da sich sonst der reine Icon-Text nach dem Hinzufügen eines Produkts nicht mehr aktualisiert und Screenreader-Nutzer die veraltete Zahl vorgelesen bekommen.

Die robusteste Umsetzung kombiniert einen visually-hidden Basistext mit einem per Alpine.js reaktiv aktualisierten, ebenfalls versteckten Zähler-Text, sodass der gesamte zugängliche Name bei jeder Änderung des Warenkorbs automatisch korrekt vorgelesen wird, ohne ein separates aria-live-Update zu benötigen, da der Name beim erneuten Fokussieren des Buttons ohnehin neu ausgelesen wird.

<button
  type="button"
  class="relative"
  x-data="{ count: 3 }"
  aria-label="Warenkorb öffnen"
>
  <svg class="w-6 h-6" aria-hidden="true"><!-- Icon-Pfad --></svg>
  <span
    class="sr-only"
    x-text="count + ' Artikel im Warenkorb'"
  ></span>
  <span
    class="absolute -top-1 -right-1 bg-red-600 text-white text-xs rounded-full px-1.5"
    aria-hidden="true"
    x-text="count"
  ></span>
</button>

7. Praxisbeispiel: das Such-Icon im Header

Das Lupensymbol im Header übernimmt in vielen Hyvä-Themes eine Doppelfunktion: Im geschlossenen Zustand öffnet es das Suchfeld, im geöffneten Zustand schließt derselbe Button die Suche wieder. Ein statisches aria-label wie Suche öffnen wird in diesem Fall nach dem ersten Klick semantisch falsch, weil der Button dann tatsächlich schließt statt öffnet, obwohl das Label unverändert bleibt.

Die korrekte Lösung bindet das aria-label reaktiv an den Öffnungszustand, sodass es je nach Zustand entweder Suche öffnen oder Suche schließen liefert, kombiniert mit aria-expanded, das den aktuellen Zustand zusätzlich strukturell für unterstützende Technologie kommuniziert, unabhängig vom reinen Textinhalt des Labels.

<button
  type="button"
  x-data="{ open: false }"
  x-on:click="open = !open"
  :aria-label="open ? 'Suche schließen' : 'Suche öffnen'"
  :aria-expanded="open"
>
  <svg class="w-6 h-6" aria-hidden="true"><!-- Lupe- oder X-Icon --></svg>
</button>

8. Praxisbeispiel: Social-Share-Icons

Bei einer Reihe von Social-Share-Icons, etwa für Facebook, X und Pinterest, wiederholt sich dasselbe Grundproblem mehrfach hintereinander: Jedes Icon muss den jeweiligen Kanal und die Aktion im zugänglichen Namen benennen, etwa Auf Facebook teilen statt lediglich Facebook, da der reine Markenname ohne Handlungsverb keine ausreichende Information über die eigentliche Funktion des Buttons liefert.

Zusätzlich sollte bei einer Gruppe zusammengehöriger Share-Buttons eine übergeordnete nav mit einem passenden aria-label wie Auf sozialen Netzwerken teilen die einzelnen Buttons semantisch bündeln, damit Screenreader-Nutzer die Gruppe als zusammenhängenden Bereich erkennen, statt fünf einzelne, kontextlose Buttons nacheinander vorgelesen zu bekommen.

9. Entscheidungshilfe: welches Pattern wann

Für statische Icon-Buttons ohne dynamischen Inhalt sind visually-hidden-Text und aria-label technisch nahezu gleichwertig, wobei visually-hidden-Text wegen der besseren Kompatibilität mit Werkzeugen außerhalb der reinen Accessibility-API die robustere Standardwahl bleibt. Für dynamische Inhalte wie den Warenkorb-Zähler eignet sich ebenfalls visually-hidden-Text besonders gut, da er sich mit denselben Reaktivitätsmechanismen aktualisieren lässt wie der Rest der Alpine.js-Komponente.

aria-label bleibt sinnvoll, wenn der zugängliche Name sich einfach und ausschließlich reaktiv aus einem Zustand ableiten lässt, wie beim Such-Icon mit den beiden Zuständen offen und geschlossen, während das title-Attribut in keinem der beschriebenen Fälle als alleinige Lösung empfehlenswert ist, sondern höchstens als zusätzlicher visueller Tooltip für Maus-Nutzer ergänzt werden sollte. Die folgende Tabelle fasst die Unterstützung der drei Patterns in gängigen Screenreadern zusammen.

10. Zusammenfassung

11. FAQ: Text-Alternativen für Icon-Buttons: Das Wichtigste auf einen Blick