Was sind barrierefreie Icons im Webdesign?

Barrierefreie Icons sind grafische Symbole im Webdesign, die für alle Nutzer wahrnehmbar, bedienbar, verständlich und robust sind. Sie erfüllen die Anforderungen der WCAG sowie des Barrierefreiheitsstärkungsgesetzes (BFSG) und sind sowohl für sehende Nutzer mit Maus als auch für Menschen mit Screenreader, Tastatur, Sprachsteuerung oder kognitiven Einschränkungen nutzbar.

Im Kern geht es um vier Aspekte: Technik (Inline SVG, ARIA, Semantik), visuelle Gestaltung (Kontrast 3:1 für Bedienelemente, Mindestgröße, klare Form), Beschriftung (sichtbares Label oder Accessible Name) und Trennung zwischen funktionalen und dekorativen Icons. Wer diese vier Punkte sauber umsetzt, erfüllt nicht nur die vier POUR Prinzipien, sondern verbessert die Usability für alle.

Seit dem 28. Juni 2025 gilt das BFSG. Barrierefreies Webdesign ist damit für Onlineshops, Banken, Buchungsplattformen und viele weitere digitale Dienste Pflicht. Icons sind dabei kein Detail am Rand, sondern Kern jeder Benutzeroberfläche, vom Hamburger Menü bis zum Warenkorb. Dieser Glossareintrag zeigt, wie du Icons 2026 nach WCAG 2.2 sauber umsetzt.

NCA arbeitet täglich mit Astro, React und Vue und baut Icon Komponenten, die screenreader sauber, tastaturbedienbar und kontraststark sind. Wir prüfen Icon Systeme, refaktorieren bestehende Komponenten und lösen alte Icon Fonts durch Inline SVG ab. Regressionen fangen wir mit Cypress und axe in der Pipeline ab, bevor sie live gehen.

Konkret unterstützen wir Teams mit barrierefreiem Webdesign und Accessibility Webdesign im Frontend, mit einem Accessibility Audit bestehender Komponenten und mit Accessibility Testing in der CI. Für Onlineshops klären wir die Anforderungen aus dem BFSG, bei komplexen Custom Components helfen wir mit sauberem ARIA.

Die technische Grundlage entscheidet darüber, wie barrierefrei ein Icon überhaupt sein kann. Inline SVG ist 2026 der klare Standard für Icons im Web. SVG skaliert verlustfrei, lässt sich über CSS gestalten, semantisch beschriften und über ARIA Attribute für Screenreader kontrollieren. Icon Fonts wie die alten Bootstrap Glyphicons oder klassische Font Awesome Bibliotheken stammen aus einer Ära ohne breiten SVG Support und bringen heute mehr Probleme als Lösungen.

Konkret gibt es drei Optionen:

• Inline SVG (empfohlen): Direkt im HTML, mit role="img" oder aria-hidden, voll stylebar, beste Screenreader Unterstützung. Auch in CSS über currentColor einfach themebar.
• Icon Fonts (vermeiden): Werden von Screenreadern oft als kryptische Unicode Zeichen vorgelesen, brechen bei eigenen Stylesheets für Sehbehinderte und sind nicht semantisch.
• Bitmap (PNG, WebP): Nur in Sonderfällen wie komplexen Illustrationen. Für UI Icons ungeeignet wegen Skalierung und Dateigröße.

Wer noch mit Icon Fonts arbeitet, sollte den Umstieg auf Inline SVG einplanen. Wir helfen Teams bei genau solchen Migrationen und kennen die typischen Fallstricke beim Refactoring größerer Codebases. Wie ein Frontend Refactoring dieser Art aussieht, zeigt unser Beitrag JavaScript ablösen für Barrierefreiheit und Performance.

Die Web Content Accessibility Guidelines definieren mehrere Erfolgskriterien, die für Icons direkt relevant sind. Wer auf WCAG 2.2 Level AA zielt, sollte diese vier kennen:

• 1.1.1 Nicht Text Inhalte (Level A): Jedes funktionale Icon braucht eine Textalternative, die den Zweck kommuniziert. Dekorative Icons werden via aria-hidden="true" ausgeblendet. Mehr dazu unter Nicht Text Inhalte.
• 1.4.11 Nicht Text Kontrast (Level AA): Icons als Bedienelemente und ihre Zustände brauchen ein Kontrastverhältnis von mindestens 3:1 zur Umgebung. Details unter Farbkontrast.
• 2.5.8 Zielgröße Minimum (Level AA, neu in WCAG 2.2) und 2.5.5 Zielgröße (Level AAA): Tap Targets brauchen mindestens 24 mal 24 CSS Pixel (AA) beziehungsweise 44 mal 44 CSS Pixel (AAA). Wir empfehlen 44 mal 44 als Best Practice für Touch Geräte.
• 4.1.2 Name Rolle Wert (Level A): Icon Buttons brauchen einen klaren Accessible Name, eine korrekte Rolle und sinnvolle Zustände. Tiefer unter Name Rolle Zustand.

Im Accessibility Audit sehen wir am häufigsten Verstöße gegen 1.4.11 und 2.5.8, also Icons mit zu wenig Kontrast oder zu kleinen Klickflächen. Beides ist mit überschaubarem Aufwand zu beheben, wenn man früh ansetzt.

Damit Screenreader und Sprachsteuerung ein Icon verstehen, braucht das interaktive Element (meist ein <button> oder <a>) einen Accessible Name. Für Icons gibt es drei bewährte Techniken. Wir empfehlen in fast allen Fällen ein sichtbares Label, weil es auch Sprachsteuerung und Übersetzungen sauber unterstützt.

Technik 1: Sichtbares Textlabel neben dem Icon. Beste Wahl für Usability und Accessibility. Das Icon wird via aria-hidden="true" versteckt, der Text liefert den Accessible Name.

Technik 2: aria-label am Button. Für Icon Only Buttons wie Hamburger Menü oder Schließen Kreuz. Browserübersetzung funktioniert nicht zuverlässig, daher nur einsetzen, wenn das sichtbare Label keine Option ist.

Technik 3: Visually Hidden Text. Robusteste Variante, weil Übersetzer und Screenreader echten DOM Text immer sauber verarbeiten. Wir nutzen das als Fallback, wenn das visuelle Design kein sichtbares Label zulässt.

Wichtig: Der Accessible Name muss zum visuellen Inhalt passen. Wenn neben dem Icon sichtbar Suche steht, sollte das aria-label nicht plötzlich Magnifying Glass heißen. Das verlangt auch WCAG 2.5.3 Label in Name. Sprachsteuerungsnutzer sprechen, was sie sehen.

WCAG 2.2 Erfolgskriterium 1.4.11 verlangt für Icons als Bedienelemente einen Kontrast von mindestens 3:1 gegenüber Hintergrund und angrenzenden Farben. Das gilt für jeden visuell wichtigen Bestandteil und auch für Fokusringe, Hover Zustände und Aktiv Zustände. Schwächt der Hover Zustand den Kontrast ab, kann das Icon plötzlich unter die Schwelle fallen.

Drei Faustregeln aus der Praxis:

• Mehr Kontrast schadet nicht. Wer auf 4.5:1 zielt (das Maß für normalen Text), liegt für Icons immer auf der sicheren Seite.
• Keine Information nur über Farbe. Ein rotes Icon für Fehler braucht zusätzlich Form, Text oder Position. Mehr dazu unter Color Accessibility.
• Fokusringe gelten auch. Der sichtbare Fokus auf einem Icon Button braucht selbst 3:1 Kontrast zum Hintergrund.

Zum Prüfen nutzen wir den Farbkontrast Rechner und Browser Tools wie den Accessibility Inspector in Firefox oder die Chrome DevTools. Contrast Enhancement ist außerdem ein eigenes Thema, das bei Designs mit niedrigem Stilkontrast schnell relevant wird.

Eine der häufigsten Fehlerquellen ist die fehlende Unterscheidung zwischen dekorativen und funktionalen Icons. Screenreader sollten nur die Icons vorlesen, die echte Information transportieren. Ein Dekoelement neben einem klaren Textlabel ist redundant und stört den Lesefluss.

Dekorativ: Icon dient nur der visuellen Aufwertung neben Text oder als reines Design Element. Es wird via aria-hidden="true" und focusable="false" aus dem Accessibility Tree entfernt.

Funktional ohne Text: Icon ist die einzige Information. Das interaktive Element braucht einen Accessible Name. Die SVG selbst wird mit aria-hidden="true" versteckt, der Name kommt vom aria-label oder einem Visually Hidden Span auf dem Button.

Inhaltsbild als Icon: Selten, aber relevant. Das Icon steht alleine im Fließtext und ist die Information selbst (z.B. ein Statussymbol in einer Tabelle). Hier nutzt man role="img" mit aria-label auf dem SVG.

Im Accessibility Audit begegnen uns immer wieder die gleichen Muster. Diese fünf Punkte decken die typischen Icon Probleme ab:

• Hamburger Menü ohne Accessible Name. Drei Striche ohne Label sind für Screenreader unsichtbar. Lösung: aria-label="Menü" am Button oder sichtbares Wort daneben.
• Icon Font mit kryptischen Unicode Zeichen. Screenreader lesen Zeichen aus der Private Use Area falsch oder gar nicht vor. Lösung: Migration auf Inline SVG.
• Klickbares Icon mit role="button" auf einem div. Funktioniert ohne eigenen Code nicht mit Enter oder Space. Lösung: Echtes <button> Element nutzen.
• Funktion nur durch Farbe kommuniziert. Roter Punkt für Fehler, grüner für ok. Bei Farbsehschwäche nicht unterscheidbar. Lösung: Form, Text und Position kombinieren.
• Klickfläche kleiner als 24 mal 24 CSS Pixel. Auf Touch Geräten schwer bedienbar. Lösung: Mindestens 24 mal 24, besser 44 mal 44 via Padding.

Wer Icons im Projekt skaliert, profitiert von einer zentralen Icon Komponente mit eingebauten Defaults für aria-hidden, focusable und viewBox. Wir bauen solche Komponenten in Astro, React und Vue. Fertige Bausteine zeigt die Sammlung Accessible Astro Components.

Barrierefreie Icons lassen sich mit einer Mischung aus automatisierten Tools, Browser DevTools und manuellen Screenreader Tests verlässlich prüfen. Automatisierte Scanner fangen typische Strukturfehler ab, ersetzen aber kein manuelles Accessibility Testing.

• Browser DevTools: Der Accessibility Inspector in Firefox und der Accessibility Tree in Chrome zeigen den Accessible Name jedes Icon Buttons. Damit findet man fehlende oder falsche Labels in Sekunden.
• ANDI: Bookmarklet der US Social Security Administration, sehr stark bei Accessible Names und ARIA.
• Silktide: Browser Extension mit gutem Quickcheck und visuellem Feedback.
• Stark: Figma und Browser Plugin für Designer und Entwickler, prüft Kontrast und Annotations.
• Echte Screenreader Tests: NVDA mit Firefox auf Windows, VoiceOver auf macOS und iOS, TalkBack auf Android. Mindestens ein realer Test je Hauptplattform.

Wir kombinieren automatisierte Cypress Tests mit axe-core und händische Screenreader Walkthroughs. Wie das Setup aussieht, zeigt der Beitrag zu axe DevTools und Cypress Accessibility Testing. So fallen Regressionen früh auf, während Menschen weiter die kritischen Pfade prüfen.

Wenn Teams ihre Seite an das BFSG anpassen, ist der Icon Layer fast immer eine der ersten Baustellen. Drei Beobachtungen aus unserer Praxis:

Erstens: Icon Libraries sind oft historisch gewachsen und mischen Icon Fonts, einzelne SVGs und CSS Backgrounds. Eine konsistente Migration auf Inline SVG mit zentraler Icon Komponente bringt sofort spürbare Verbesserungen für Screenreader, Performance und Wartbarkeit.

Zweitens: Viele Projekte testen Icons gar nicht oder nur einmal zum Launch. Wir empfehlen Accessibility Testing direkt in der Pipeline, damit Regressionen früh auffallen. Cypress mit axe liefert dabei verlässliche Ergebnisse für die kritischen Pfade, ein Überblick steht bei den Accessibility Testing Tools.

Drittens: Design und Entwicklung arbeiten oft mit unterschiedlichen Annahmen. Ein gemeinsames Icon Briefing mit klaren Regeln zu Mindestgröße, Touch Target, Label und Kontrast spart später viele Iterationen. Wir bringen die POUR Prinzipien direkt in die Designsysteme der Teams.

Wer eine bestehende Seite mit barrierefreiem Webdesign modernisieren will, startet am besten mit einem Accessibility Audit. Danach wissen Teams genau, wo sie stehen und welche Schritte den größten Hebel haben. Wie Bilder und Grafiken richtig beschriftet werden, erklärt der Eintrag zum Alternativtext.

Diese Fragen hören wir regelmäßig rund um barrierefreie Icons. Die Antworten spiegeln den Stand von WCAG 2.2 im Jahr 2026 wider.