Barrierefreie Texte sind sprachliche Inhalte in digitalen Produkten, die so gestaltet sind, dass sie von allen Menschen genutzt werden können – einschließlich Personen, die Screenreader nutzen, Tastaturnavigation bevorzugen oder kognitive Einschränkungen haben.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UX Writing & Content Design · Niveau: Fortgeschritten Synonyme / Auch bekannt als: Accessibility Writing, Inclusive Writing, Barrierefreiheit in UX Texten, A11y Writing
Was sind barrierefreie Texte?
Barrierefreiheit (englisch: Accessibility, kurz A11y) in digitalen Produkten bedeutet, dass alle Menschen – unabhängig von körperlichen oder kognitiven Einschränkungen – ein Interface vollständig nutzen können. UX Writer spielen dabei eine unterschätzte Rolle: Viele Barrierefreiheitsprobleme entstehen nicht durch schlechtes Design, sondern durch fehlende oder schlecht formulierte Texte.
In der Europäischen Union ist digitale Barrierefreiheit seit dem Barrierefreiheitsstärkungsgesetz (BFSG, 2025) für eine wachsende Zahl digitaler Produkte und Dienstleistungen verpflichtend. Der internationale Standard ist die Web Content Accessibility Guidelines (WCAG 2.1) des W3C.
Erklärung
Alt-Text für Bilder
Was ist Alt-Text? Alt-Text (Alternativtext) ist eine textuelle Beschreibung eines Bildes. Screenreader lesen diesen Text vor, wenn ein Bild nicht visuell wahrgenommen werden kann. Alt-Text erscheint auch, wenn ein Bild nicht geladen wird.
Guten Alt-Text schreiben:
- Beschreibe, was zu sehen ist, nicht wie es heißt: „Frau hält Laptop und lächelt" statt „Stock-Foto Frau mit Laptop"
- Kontext beachten: Was ist die Funktion des Bildes im Kontext? Ein dekoratives Bild braucht alt="" (leer), nicht eine Beschreibung.
- Kein „Bild von" oder „Foto zeigt": Screenreader identifizieren Bilder selbst als Bilder.
- Länge: 100–150 Zeichen sind ideal; für komplexe Grafiken oder Diagramme kann ein längerer Beschreibungstext sinnvoll sein.
- Texte in Bildern: Müssen im Alt-Text vollständig wiederholt werden.
Beispiele:
- Dekoratives Bild:
alt="" - Produktbild:
alt="Rotes Lederportemonnaie, drei Kartenfächer, Reißverschlussfach" - Infografik:
alt="Balkendiagramm: Nutzung sozialer Medien 2023. Instagram 42 %, TikTok 31 %, Facebook 20 %"
ARIA-Labels
Was sind ARIA-Labels? ARIA (Accessible Rich Internet Applications) ist eine Spezifikation für zusätzliche semantische Informationen in HTML, die Screenreadern helfen, interaktive Elemente korrekt zu kommunizieren.
aria-label: Gibt einem Element einen zugänglichen Namen.
Beispiel: Ein Icon-Button ohne sichtbaren Text: ``html <button aria-label="Suche öffnen">🔍</button> ``
aria-labelledby: Verknüpft ein Element mit einem anderen Element, das es beschriftet.
aria-describedby: Verknüpft ein Element mit einem erklärenden Text (z. B. Hilfetext für ein Formularfeld).
Wann brauche ich ARIA-Labels?
- Bei Icon-Buttons ohne sichtbaren Text
- Bei Formularen, bei denen Label und Feld nicht programmatisch verknüpft sind
- Bei komplexen Widgets (Sliders, Accordions, Tabs)
- Bei dynamischen Inhalten, die sich ohne Seitenreload aktualisieren (aria-live)
Screenreader-Optimierung
Screenreader-Nutzer navigieren Seiten anders als sehende Nutzer: Sie springen von Überschrift zu Überschrift, von Link zu Link oder von Formularfeld zu Formularfeld. Das hat direkte Konsequenzen für das UX Writing:
Überschriftenhierarchie: Überschriften müssen logisch strukturiert sein (H1 → H2 → H3). Sie dienen als Navigation, nicht nur als visuelle Gestaltung.
Linktext: „Hier klicken" und „Mehr lesen" sind für Screenreader-Nutzer nutzlos, da sie aus dem Kontext gerissen werden. Besser: „Barrierefreiheitsrichtlinie herunterladen" oder „Mehr über unsere Preispläne erfahren".
Fehlermeldungen: Fehlermeldungen in Formularen müssen programmatisch mit dem betreffenden Feld verknüpft sein (aria-describedby oder aria-errormessage) und von Screenreadern automatisch vorgelesen werden (aria-live="assertive"). Vgl. Fehlertext-Design.
Buttons vs. Links: Buttons lösen Aktionen aus, Links navigieren. Diese Unterscheidung ist für Tastatur- und Screenreader-Nutzer essentiell. Die Beschriftung muss die Funktion widerspiegeln – vgl. Button-Beschriftung.
Plain Language als Barrierefreiheitsmaßnahme
Plain Language: Verständlich schreiben ist nicht nur ein Stilmerkmal, sondern eine Accessibility-Maßnahme: Klare Sprache hilft Menschen mit Legasthenie, kognitiven Beeinträchtigungen, Nicht-Muttersprachlern und allen, die unter Zeitdruck lesen. WCAG 3.1.5 empfiehlt einen Lesbarkeitsgrad, der der 9. Klasse entspricht oder darunter liegt.
Farbunabhängige Kommunikation
WCAG 1.4.1 schreibt vor, dass Informationen nicht ausschließlich über Farbe kommuniziert werden dürfen. Für UX Writer bedeutet das: Fehlermeldungen müssen auch textlich signalisiert werden (nicht nur durch rote Farbe), und Statusanzeigen müssen textliche Labels haben. Vgl. Fehlertext-Design.
Beispiele
Schlechter Link-Text:
„Klicken Sie hier für mehr Informationen."
Guter Link-Text:
„Barrierefreiheitserklärung der Lazi-Akademie lesen"
Schlechtes Formular-Label (nur Placeholder):
<input placeholder="E-Mail">Barrierefreies Formular-Label:
<label for="email">E-Mail-Adresse</label><input id="email" type="email">Schlechter Button (nur Icon):
<button>🗑️</button>Barrierefreier Button:
<button aria-label="Datei löschen">🗑️</button>In der Praxis
Accessibility-Checkliste für UX Writer
- [ ] Alle Bilder haben sinnvollen Alt-Text (oder leeres alt bei Dekorationsgrafiken)
- [ ] Link-Texte sind aus dem Kontext heraus verständlich
- [ ] Fehlermeldungen enthalten textliche Informationen, nicht nur Farbe
- [ ] Button-Texte beschreiben die Aktion, nicht nur „OK" oder Icon
- [ ] Formular-Labels sind sichtbar und programmatisch verknüpft
- [ ] ARIA-Labels für alle Icon-Buttons gesetzt
- [ ] Sprache ist einfach und klar (Plain Language)
- [ ] Dokumente haben logische Überschriftenhierarchie
Tools für Accessibility-Tests
- axe DevTools: Browser-Extension für automatische Accessibility-Prüfung
- NVDA / JAWS / VoiceOver: Screenreader zum manuellen Testen
- Hemingway Editor: Prüft Lesbarkeit und Komplexität von Texten
- Weitere: Tools für UX Writer
Vergleich & Abgrenzung
Barrierefreiheit vs. Usability: Barrierefreiheit ist eine Grundvoraussetzung; Usability beschreibt die Effizienz und Freude der Nutzung. Ein Produkt kann usable aber nicht barrierefrei sein – und umgekehrt.
Alt-Text vs. Caption: Alt-Text ist für Screenreader und taucht nicht für alle Nutzer auf. Ein Caption (Bildunterschrift) ist sichtbarer Text unter einem Bild, der für alle Nutzer zugänglich ist.
ARIA vs. semantisches HTML: ARIA ist ein Fallback, wenn semantisches HTML nicht ausreicht. Best Practice: zuerst semantisches HTML verwenden, dann ARIA nur dort, wo nötig.
Häufige Fragen (FAQ)
Ist Barrierefreiheit in Deutschland gesetzlich vorgeschrieben? Ja, mit dem BFSG (Barrierefreiheitsstärkungsgesetz) müssen ab dem 28. Juni 2025 viele digitale Produkte und Dienstleistungen die Anforderungen der WCAG 2.1 Level AA erfüllen.
Was ist WCAG und welches Level brauche ich? Die Web Content Accessibility Guidelines (WCAG) des W3C haben drei Konformitätsstufen: A (Minimum), AA (Standard, rechtlich gefordert), AAA (anspruchsvoll). Level AA ist der gültige Standard.
Brauche ich als UX Writer Programmierkenntnisse für Accessibility? Nicht tief, aber ein grundlegendes Verständnis von HTML-Semantik und ARIA ist sehr hilfreich, um mit Entwicklern sinnvoll über Accessibility zu kommunizieren.
Was sind die häufigsten Accessibility-Fehler in UX Texten? Fehlende Alt-Texte, generische Link-Texte ("hier klicken"), Labels nur als Placeholder, und Fehlermeldungen nur über Farbe.
Verwandte Einträge
- Plain Language: Verständlich schreiben
- Formular-UX-Writing
- Fehlertext-Design
- Button-Beschriftung
- Tools für UX Writer
Weiterführend
- W3C: Web Content Accessibility Guidelines (WCAG) 2.1, w3.org/TR/WCAG21, 2018
- Torrey, Preston / Quesenbery, Whitney: A Web for Everyone, Rosenfeld Media, 2014
- Bundesfachstelle Barrierefreiheit: Leitfaden Barrierefreiheit digitaler Angebote, 2023
- WebAIM: „Alternative Text", webaim.org/techniques/alttext, aktuell gepflegt
