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 Inkrafttreten des BFSG am 28. Juni 2025 ist barrierefreies Webdesign für Onlineshops, Banken, Buchungsplattformen und viele weitere digitale Dienste verpflichtend. Icons sind dabei kein Detail am Rand, sondern Kern jeder modernen Benutzeroberfläche, vom Hamburger Menü bis zum Warenkorb. Dieser Glossareintrag zeigt, wie Icons 2026 nach WCAG 2.2 sauber umgesetzt werden.

NCA berät seit Jahren Unternehmen, Verlage und Onlineshops bei der Umsetzung digitaler Barrierefreiheit nach WCAG und BFSG. Wir auditieren Icon Systeme, refaktorieren bestehende Komponenten und entwickeln SVG Icon Libraries, die screenreader sauber, tastaturbedienbar und kontraststark sind. Unsere eigenen Frontend Projekte mit Astro, React und Vue laufen produktiv mit barrierefreien Icon Komponenten, die wir laufend weiterentwickeln.

Konkret unterstützen wir Teams beim barrierefreien Webdesign rund um Icons, beim Accessibility Audit bestehender Komponenten, beim Accessibility Testing mit echten Tools, bei der BFSG Compliance für Onlineshops und im ARIA Umfeld bei komplexen Custom Components. Auch beim Refactoring alter Icon Fonts auf Inline SVG haben wir tiefe Erfahrung und kennen die typischen Stolperfallen.

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 sehen wir 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 custom CSS 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. NCA hat genau solche Migrationen bereits durchgeführt und kennt die typischen Fallstricke beim Refactoring größerer Codebases.

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.5 Zielgröße (Level AAA) und 2.5.8 Zielgröße Minimum (Level AA WCAG 2.2): Tap Targets sollen mindestens 24x24 Pixel umfassen (AA) beziehungsweise 44x44 Pixel (AAA). NCA empfiehlt 44x44 Pixel 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.

In Accessibility Audits 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 stehen drei bewährte Techniken zur Verfügung. NCA empfiehlt in fast allen Fällen 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 in NCA Projekten 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. 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 NCA Audits:

• 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.
• Kein Information by Color allein. 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 die Accessibility Inspector in Firefox oder 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.

In Audits begegnen uns immer wieder die gleichen Muster. Wer diese fünf Punkte abhakt, deckt rund 80 Prozent der 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 liest "Private Use Area" vor. Lösung: Migration auf Inline SVG.
• Klickbares Icon mit role="button" auf einem div. Funktioniert nicht mit Enter oder Space auf der Tastatur. Lösung: Echtes <button> Element nutzen.
• Funktion nur durch Farbe kommuniziert. Roter Punkt für Fehler, grüner für ok. Bei Farbenblindheit unsichtbar. Lösung: Form, Text und Position kombinieren.
• Klickfläche kleiner als 24x24 Pixel. Auf Touch Geräten unbedienbar. Lösung: Mindestens 24x24 Pixel, besser 44x44 Pixel via Padding.

Wer Icons im Projekt skaliert, profitiert von einer zentralen Icon Komponente mit eingebauten Defaults für aria-hidden, focusable und viewBox. NCA hat solche Komponenten in Astro, React und Vue mehrfach implementiert.

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 von 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 in NCA Beratungsprojekten automatisierte Cypress Tests mit axe-core Plugin und händische Screenreader Walkthroughs. Damit fangen wir Regressionen früh ab, während die kritischen Pfade weiterhin von Menschen geprüft werden.

In Beratungsprojekten zur BFSG Compliance ist der Icon Layer fast immer eine der ersten Baustellen. Drei Beobachtungen aus unserer Praxis:

Erstens: Bestehende 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: Die meisten Projekte testen Icons gar nicht oder nur einmalig zum Launch. Wir empfehlen Accessibility Testing direkt in der Pipeline, damit Regressionen früh auffallen. Cypress mit dem axe Plugin liefert dabei verlässliche Ergebnisse für die kritischen Pfade.

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

Wer eine bestehende Webseite barrierefrei machen möchte und beim Thema Icons unsicher ist, holt sich am besten ein Accessibility Audit ins Haus. Nach einem Audit wissen Teams genau, wo sie stehen und welche Schritte den größten Hebel haben.

Die folgenden Fragen begegnen uns regelmäßig in Beratungsprojekten und Audits rund um barrierefreie Icons. Die Antworten spiegeln den Stand von WCAG 2.2 und unserer Praxiserfahrung 2026 wider.