Accessibility-Checks in Figma umfassen Werkzeuge, Plugins und Methoden, mit denen Designer bereits in der Design-Phase sicherstellen, dass ihre UI-Entwürfe den WCAG-Richtlinien entsprechen und für alle Nutzer zugänglich sind.
Rubrik: Software & Tools Deep-Dive · Unterrubrik: Figma · Niveau: Fortgeschritten Synonyme / Auch bekannt als: A11y in Figma, Barrierefreiheits-Checks, WCAG-Prüfung im Design
Was ist Accessibility in Figma?
Accessibility (Barrierefreiheit, kurz A11y) im Design-Kontext bedeutet, dass digitale Produkte von Menschen mit Behinderungen – visuell, motorisch, kognitiv oder auditiv – vollständig genutzt werden können. Die internationale Richtlinie WCAG (Web Content Accessibility Guidelines) der W3C definiert Mindeststandards.
Figma selbst hat keine vollständige WCAG-Compliance-Engine, bietet aber:
- Native Annotations für Accessibility-Dokumentation
- Kontrast-Check im Design-Panel
- Umfangreiche Plugin-Unterstützung (besonders Stark)
- Strukturierungsmöglichkeiten für Screen-Reader-Kommunikation
Erklärung
Farb- und Kontrastprüfung
WCAG-Kontrastanforderungen:
- AA-Standard (Mindestanforderung): 4,5:1 für normalen Text, 3:1 für großen Text (18px+ fett oder 24px+)
- AAA-Standard (erhöhte Anforderung): 7:1 für normalen Text, 4,5:1 für großen Text
Figma Native: Der integrierte Figma-Kontrast-Checker erscheint im Design-Panel, wenn Text auf einem Hintergrund ausgewählt wird. Er zeigt das Kontrastverhältnis und AA/AAA-Status an.
Stark Plugin: Das umfangreichste Accessibility-Plugin für Figma. Funktionen:
- Vollständige WCAG 2.1 AA/AAA-Kontrastprüfung
- Farbblindheits-Simulationen (8 Typen: Protanopia, Deuteranopia, Tritanopia etc.)
- Focus Order Visualisierung
- Alt-Text-Generierung für Bilder
- Accessibility Annotations Export für Entwickler
Farbblindheits-Simulation
Etwa 8% der männlichen und 0,5% der weiblichen Bevölkerung sind von einer Form von Farbblindheit betroffen (Birch, 2012). Stark und andere Plugins simulieren, wie ein Design für Personen mit verschiedenen Farbwahrnehmungsbeeinträchtigungen aussieht.
Praxistipp: Niemals allein auf Farbe als einziges Unterscheidungsmerkmal setzen. Immer zusätzliche Hinweise nutzen: Icons, Muster, Labels, Formen.
Accessibility Annotations
Figma bietet (besonders im Dev Mode) die Möglichkeit, Accessibility-Annotations direkt auf Frames zu platzieren:
- ARIA-Rollen (button, link, heading, etc.)
- Alt-Texte für Bilder
- Tab-Order-Nummerierung
- Focus-States markieren
Diese Annotations sind im Figma: Dev Mode – Die Brücke zwischen Design und Entwicklung für Entwickler sichtbar und helfen bei der korrekten semantischen HTML-Implementierung.
Focus Order und Keyboard Navigation
Eine zugängliche UI muss vollständig per Tastatur bedienbar sein. In Figma kann die Focus Order (Tab-Reihenfolge) mit dem Stark Plugin oder manuell mit nummerierten Annotations dokumentiert werden. Die logische Reihenfolge sollte dem visuellen Lesefluss entsprechen: links nach rechts, oben nach unten (für westliche Layouts).
Typografie und Lesbarkeit
Mindestschriftgrößen:
- Body-Text: mindestens 16px (physisches Äquivalent)
- Kleintext: nicht unter 12px (außer dekorativ)
Zeilenlänge: Optimal: 45–75 Zeichen pro Zeile für beste Lesbarkeit (Bringhurst, 2004).
Zeilenabstand: WCAG empfiehlt mindestens 1,5× die Schriftgröße als Zeilenhöhe.
In Figma können diese Werte direkt in Figma: Styles – Zentral verwaltete Design-Tokens für Farben und Typografie als Textstile kodiert werden.
Touchziele (Touch Target Size)
Für mobile Interfaces definieren WCAG 2.5.5 (AAA) und die Apple Human Interface Guidelines Mindestgrößen:
- WCAG: 44×44 CSS-Pixel
- Apple: 44×44 pt
- Google Material Design: 48×48 dp
In Figma sollten interaktive Elemente (Buttons, Links, Icons) mindestens 44×44px groß sein oder einen entsprechend großen Hit-Bereich haben.
Beispiele
Beispiel 1: Kontrastprüfung während des Designs Ein Designer wählt für den primären CTA-Button einen blauen Hintergrund (#1E88E5) mit weißem Text. Stark zeigt sofort: Kontrastverhältnis 3,2:1 – nicht WCAG-AA-konform. Der Designer dunkelt den Blauwert auf #1565C0 ab und erreicht 5,1:1 – AA-konform.
Beispiel 2: Farbblindheits-freundliche Datenvisualisierung Ein Infografik-Designer prüft sein Diagramm mit der Protanopia-Simulation. Rot und Grün sind kaum unterscheidbar. Lösung: unterschiedliche Formen (Kreis vs. Dreieck) und direkte Labels statt alleiniger Farbkodierung.
Beispiel 3: Accessibility Annotations für Entwickler Nach Abschluss des Designs fügt der UX-Designer mit dem Stark Plugin Annotations hinzu: Jede interaktive Komponente erhält eine ARIA-Rolle, Bilder erhalten Alt-Texte, die Tab-Reihenfolge wird nummeriert. Im Figma: Dev Mode – Die Brücke zwischen Design und Entwicklung sehen Entwickler alle nötigen Accessibility-Informationen ohne Rückfragen.
In der Praxis
Accessibility-Checks sollten nicht als abschließende QA-Maßnahme verstanden werden, sondern den gesamten Designprozess begleiten:
In der Design-Phase:
- Kontrast bei jeder Farbentscheidung prüfen
- Textstile mit korrekten Zeilenhöhen definieren
- Farbblindheits-Simulation für alle Screens
Vor dem Handoff:
- Vollständige Annotations ergänzen
- Focus Order dokumentieren
- Accessibility-Report mit Stark exportieren
Nach dem Handoff:
- Developers verwenden Annotations aus dem Dev Mode
- Automatisierte Tests (z.B. axe, Lighthouse) ergänzen die manuelle Prüfung
Rechtlicher Kontext (Deutschland): Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet ab Juni 2025 Anbieter digitaler Produkte und Dienstleistungen zur Barrierefreiheit nach EN 301 549 (basierend auf WCAG 2.1 AA). Für Medienproduzenten und Publisher mit digitalen Angeboten relevant.
Vergleich & Abgrenzung
Figma Stark vs. A11y Color Contrast Checker: Stark ist das umfassendere Tool (Farbblindheit, Focus Order, Annotations), A11y ist einfacher und schneller für reine Kontrast-Checks.
Design-Phase Accessibility vs. Code-Phase Accessibility: Figma-Checks identifizieren visuelle Accessibility-Probleme. Semantisches HTML, ARIA-Attribute und Tastaturnavigation müssen in der Implementierung sichergestellt werden. Tools wie axe DevTools, Lighthouse oder NVDA Screen Reader ergänzen die Design-Phase.
Häufige Fragen (FAQ)
Reicht WCAG AA oder brauche ich AAA? Für die meisten kommerziellen Projekte ist AA der rechtliche und praktische Mindeststandard. AAA wird für spezifische Zielgruppen (z.B. Sehbehinderte) oder besonders zugänglichkeitsorientierte Projekte angestrebt.
Wie viele Nutzer profitieren von Accessibility-Maßnahmen? Laut WHO haben weltweit etwa 2,2 Milliarden Menschen eine Sehbeeinträchtigung, 466 Millionen eine Hörbeeinträchtigung. Accessibility-Maßnahmen helfen aber auch situativ (starke Sonneneinstrahlung, laute Umgebung) und temporär (gebrochener Arm).
Ist Figma selbst accessible? Figma hat Verbesserungen an seiner eigenen Interface-Accessibility vorgenommen, ist aber für Screen-Reader-Nutzer noch nicht vollständig zugänglich. Die Community fordert hier weitere Fortschritte.
Verwandte Einträge
- Figma Plugins: Übersicht und Empfehlungen – Stark und A11y-Plugins
- Figma: Dev Mode – Die Brücke zwischen Design und Entwicklung – Accessibility Annotations im Handoff
- Figma: Styles – Zentral verwaltete Design-Tokens für Farben und Typografie – Typografie-Styles für Lesbarkeit
- Figma: Design Tokens – Die gemeinsame Sprache von Design und Code – Accessibility-konforme Token-Definitionen
- Figma: Components – Wiederverwendbare UI-Bausteine im Design System – Zugängliche Komponenten bauen
Weiterführend
- W3C (2023): Web Content Accessibility Guidelines (WCAG) 2.1.
- Birch, J. (2012): Worldwide Prevalence of Red-Green Color Deficiency. Journal of the Optical Society of America.
- Bringhurst, R. (2004): The Elements of Typographic Style. 3. Auflage. Hartley & Marks.
- Stark (2024): Accessibility Toolkit for Figma.
- Bundesministerium für Arbeit und Soziales (2021): Barrierefreiheitsstärkungsgesetz (BFSG).
