Dieser Text kann auch als PDF Datei heruntergeladen werden.
Was ist gemeint?
Digitale Barrierefreiheit hängt immer von zwei Seiten ab: der individuellen Unterstützung durch das Betriebssystem und der barrierefreien Gestaltung der Anwendung selbst. Nur wenn beide Seiten zusammenspielen, entsteht ein wirklich zugängliches Nutzungserlebnis.
Moderne Betriebssysteme wie Windows, macOS, iOS oder Android stellen zahlreiche integrierte Funktionen bereit, mit denen sich die Darstellung und Bedienung digitaler Inhalte individuell anpassen lässt, etwa durch Screenreader, Vergrößerung, Farbfilter oder Spracheingabe. Diese systemweiten Einstellungen bieten vielen Menschen mit Beeinträchtigungen eine wertvolle Hilfe, um digitale Geräte besser zu nutzen.
Entscheidend ist aber: Diese Funktionen können ihre Wirkung nur dann entfalten, wenn Webauftritte, mobile Anwendungen oder Dokumente auch technisch barrierefrei entwickelt sind. Für Nutzende bieten die integrierten Funktionen einen Einstiegspunkt, um Geräte an die eigenen Bedürfnisse anzupassen. Sollten diese Funktionen nicht ausreichen, gibt es insbesondere unter Windows alternative Werkzeuge, die zusätzliche Unterstützung bieten.
Für Entwickler und Entwicklerinnen bedeutet das: Wer Inhalte barrierefrei gestalten möchte, kann und sollte diese mit den vorhandenen Systemfunktionen testen. Viele dieser Werkzeuge sind kostenfrei verfügbar oder bereits ins System integriert. So lassen sich Barrieren schnell identifizieren und vermeiden.
Mit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) im Juni 2025 ist digitale Barrierefreiheit kein freiwilliger Bonus mehr, sondern eine gesetzliche Verpflichtung für viele Bereiche der Privatwirtschaft. Für öffentliche Stellen gilt diese Pflicht schon seit längerem, sie müssen digitale Angebote bereits heute barrierefrei bereitstellen, etwa nach den Vorgaben der BITV 2.0.
Die gute Nachricht: Ein Großteil der technischen Voraussetzungen ist bereits vorhanden, direkt in den Geräten, die täglich genutzt werden. Betriebssysteme und Browser bieten viele Funktionen, die sowohl Nutzenden als auch Entwickelnden helfen können, Barrierefreiheit effektiv umzusetzen. Voraussetzung ist, dass diese Funktionen korrekt unterstützt und sinnvoll genutzt werden.
In diesem Guide zeigen wir euch, welche Funktionen einige Betriebssysteme und Browser standardmäßig anbieten. Ziel ist es, ein besseres Verständnis für bestehende Möglichkeiten zu schaffen und praktische Hinweise für die bessere Gestaltung digitaler Angebote zu geben, basierend auf dem, was bereits heute zur Verfügung steht.
Warum sind systemweite Einstellungen wichtig für die Barrierefreiheit?
Barrierefreiheit beginnt nicht erst auf der Ebene einzelner Webauftritte oder mobilen Anwendungen, sondern viel früher, in den Systemen, mit denen Menschen digitale Inhalte überhaupt wahrnehmen können. Wenn Betriebssysteme und Browser grundlegende Barrierefreiheitsfunktionen bereitstellen, ermöglicht das vielen Nutzenden einen eigenständigen und gleichberechtigten Zugang zu digitalen Angeboten.
Systemeigene Funktionen wie Screenreader, Vergrößerungswerkzeuge, Farbfilter oder Spracheingabe wirken übergreifend. Wenn Webauftritte, Dokumente oder mobile Anwendungen barrierefrei gestaltet und umgesetzt werden, erhöht sich die Nutzbarkeit für eine große Zahl von Menschen erheblich.
Darüber hinaus schaffen systemintegrierte Funktionen Konsistenz. Nutzende können ihre bevorzugten Einstellungen zentral festlegen und müssen sie nicht in jeder Anwendung neu suchen. Das reduziert kognitive Belastung und macht digitale Inhalte zugänglicher, auch für Personen mit geringer Technikaffinität oder temporären Einschränkungen.
Schließlich trägt die konsequente Unterstützung dieser systemeigenen Funktionen dazu bei, gesetzliche Anforderungen wie die des BFSG, des BGG und der EN 301 549 zu erfüllen. Wer barrierefreie Inhalte gestalten möchte, sollte sich daher mit den Möglichkeiten vertraut machen, die die jeweiligen Betriebssysteme und Browser bereits mitbringen.
Warum lohnt sich die Nutzung von Systemfunktionen?
Keine Zusatzsoftware: Die Funktionen sind in Betriebssystemen und Browsern bereits enthalten und sofort verfügbar.
Systemweite Wirkung: Einstellungen gelten in allen Webauftritten und mobilen Anwendungen. Das schafft Konsistenz und verringert die kognitive Belastung.
Einfachere Umsetzung barrierefreier Inhalte: Wenn Webauftritte und mobile Anwendungen so gestaltet sind, dass sie mit den Barrierefreiheitsfunktionen des Betriebssystems gut zusammenarbeiten, sind keine zusätzlichen technischen Lösungen innerhalb des Webauftritts oder der App notwendig.
Geringere Einstiegshürden für Nutzende: Voreingestellte Systemfunktionen ermöglichen eine einfache, intuitive Bedienung, ohne aufwendige Konfiguration.
Kompatibilität mit assistiven Technologien: Sind Anwendungen technisch so gestaltet, dass sie von gängigen Hilfsmitteln wie Screenreadern, Bildschirmvergrößerung oder Sprachsteuerung erkannt und verarbeitet werden können, funktionieren diese verlässlicher.
Effektivität wird gesteigert: Wenn Nutzende sich auf die systemweiten Funktionen verlassen können, müssen sie sich nicht in jeder Anwendung neu mit individuellen Bedienhilfen oder versteckten Einstellungen auseinandersetzen..
Welche Einstellungen sind möglich?
Vergrößern des Bildschirms (Bildschirmlupe, Zoom): Ermöglicht das stufenweise Vergrößern von Inhalten – wichtig für sehbeeinträchtigte Personen.
Farbanpassungen (Kontrastmodus, Farbfilter, Farbeinstellungen): Nutzende können Farben umkehren, Kontraste erhöhen oder Filter nutzen (z. B. bei Rot-Grün-Schwäche).
Spracherkennung: Nutzende steuern Anwendungen oder geben Texte per Stimmeingabe ein (z. B. „Diktierfunktion“ in Betriebssystemen).
Bildschirmtastatur: Virtuelle Tastatur zur Eingabe per Maus, Touch oder alternativer Steuerung.
Mono-Audio: Gleicht Tonkanäle aus, sodass kein räumliches Hören notwendig ist – hilfreich bei einseitigem Hörvermögen.
Schaltersteuerung (Switch Control): Ermöglicht die Bedienung über einzelne Tasten, Blasröhrchen oder andere alternative Eingabegeräte.
Gestensteuerung und Touchhilfen: Anpassung der Touchbedienung, z. B. durch vereinfachte Gesten oder AssistiveTouch.
Live-Untertitel und Transkription: Automatische Untertitel bei Videos oder Gesprächen (z. B. in Videokonferenzen oder Medienplayern).
TTS (Text-to-Speech)/Vorlesefunktion: Text wird automatisch in Sprache umgewandelt.
Eye Tracking: Ermöglicht die Steuerung des Cursors mit den Augen.
Lupe / Kamera-Zoom für reale Objekte: Vergrößert reale Objekte über die Kamera, unterstützt z. B. beim Lesen von Texten auf Papier.
Soundverstärker und Hörhilfen: Verstärken Umgebungsgeräusche oder leiten Ton direkt an Hörgeräte (z. B. über Bluetooth).
Reader-Modus / Lesemodus (Plastischer Reader): Blendet störende Elemente aus und zeigt nur den Hauptinhalt einer Seite an.
Benutzerdefinierte Schriftgrößen: Nutzende können die Textgröße anpassen.
Caret-Browsing (mit F7): Ermöglicht die Navigation im Text mit der Tastatur (Pfeiltasten), z. B. zum Markieren und Kopieren von Text.
Welche Plattformen bieten welche Funktionen?
Die folgenden Tabellen geben einen Überblick darüber, welche Barrierefreiheitsfunktionen in den gängigen Betriebssystemen (Windows, macOS, iOS/iPadOS, Android) und in den meistgenutzten Browsern (Firefox, Chrome, Safari, Microsoft Edge) verfügbar sind. Dabei wird aufgezeigt, welche Funktionen standardmäßig vollständig vorhanden sind, welche nicht angeboten werden und wo es nur eine eingeschränkte Unterstützung gibt.
Diese Übersicht hilft dabei einzuschätzen, welche Systeme bereits umfangreiche Barrierefreiheitsfunktionen mitbringen und bei welchen ergänzenden Lösungen notwendig sein könnten.
Betriebssysteme: Stand Juni 2025
Legende:
Funktion ist vollständig verfügbarFunktion ist nur eingeschränkt verfügbarFunktion ist nicht vorhanden
Funktion
Windows 10/11
macOS
iOS/iPadOS
Android
Screenreader
Bildschirmvergrößerung
TTS (Vorlesen)
Farbfilter / Farbkorrektur
Hoher Kontrast
Spracherkennung
Bildschirmtastatur
Mono-Audio
Schaltersteuerung (Switch Control)
Gestensteuerung und Touchhilfen
Live-Untertitel und Transkription
Eye Tracking
(ab iOS 17+)
Lupe / Kamera-Zoom für reale Objekte
Soundverstärker und Hörhilfen
Systembezeichnungen im Überblick
Barrierefreiheitsfunktionen tragen je nach Betriebssystem unterschiedliche Namen. Um die Orientierung zu erleichtern, sind im folgenden Abschnitt die wichtigsten Funktionen noch einmal mit ihrer jeweiligen Bezeichnung in Windows, macOS, iOS/iPadOS und Android aufgeführt. So lässt sich gezielt nachvollziehen, wo sich welche Einstellung finden lässt.
Screenreader:
Windows: Narrotor
macoS: VoiceOver
iOS/iPadOS; VoiceOver
Android: TalkBack
Bildschirmvergrößerung:
Windows: Bildschrimlupe
macoS: Zoom
iOS/iPadOS; Zoom
Android: Vergrößerung
TTS (Vorlesen)
Windows: Sprachausgabe
macoS: VoiceOver
iOS/iPadOS; VoiceOver
Android: TalkBack
Spracherkennung
iOS/iPadOS; Siri, Diktat
Android: Google Assistant
Gestensteuerung und Touchhilfen
iOS/iPadOS: AssistiveTouch
Live-Untertitel und Transkription
iOS/iPadOS; Live Caption
Android: Live Transcribe
Lupe / Kamera-Zoom für reale Objekte
iOS/iPadOS: Lupe App
Android: Google Lookout
Soundverstärker und Hörhilfen
macoS: Made for iPhone Hörgeräte
iOS/iPadOS; Hörhilfen
Android: Sound Amplifierowser:
Browser Stand Juni 2025
Legende:
Funktion ist vollständig verfügbarFunktion ist nur eingeschränkt verfügbarFunktion ist nicht vorhanden
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Einleitung
Barrierefreiheit kostet Geld. Schlechte Barrierefreiheit kostet meistens mehr. Barrierefreiheit darf weder als Luxus noch als lästige Zusatzleistung verstanden werden, sondern als Qualitätsanforderung mit Kostenfolgen.
Ein grundlegendes Problem ist, dass Barrierefreiheit noch immer als Zusatzleistung verstanden wird. Zunächst wird ein Webauftritt, eine Anwendung oder ein digitales Verfahren geplant und umgesetzt. Erst kurz vor der Veröffentlichung oder sogar danach wird geprüft, ob das Ergebnis barrierefrei ist.
Das kann dazu führen, dass Leistungen doppelt bezahlt werden: zuerst für die ursprüngliche Umsetzung und anschließend für Korrekturen, Nacharbeiten und erneute Tests. In manchen Fällen lässt sich Barrierefreiheit nachträglich nur mit erheblichem Aufwand herstellen. Dadurch entsteht schnell der Eindruck, Barrierefreiheit sei besonders teuer. Tatsächlich liegt ein Teil der hohen Kosten jedoch darin begründet, dass sie zu spät berücksichtigt wurde.
Gute Barrierefreiheit entsteht nicht durch möglichst teure Einzelmaßnahmen, sondern durch ganzheitliche Planung, klare Anforderungen, fachkundige Umsetzung und echte Qualitätssicherung.
Dieser Leitfaden zeigt, woran ihr Angebote erkennen könnt, die die Barrierefreiheit nachhaltig in eurem Projekt implementieren.
Worum geht es?
Viele Organisationen stellen sich bei digitaler Barrierefreiheit zuerst die Kostenfrage: Wie teuer wird das? Reicht ein günstiges Tool? Muss eine vollständige Prüfung beauftragt werden? Können wir Barrierefreiheit mit einem Plugin lösen?
Diese Fragen sind nachvollziehbar. Barrierefreiheit muss planbar und bezahlbar sein. Gleichzeitig darf der Preis nicht das einzige Entscheidungskriterium sein. Ein günstiges Angebot kann sinnvoll sein, wenn klar beschrieben wird, was genau geleistet wird. Problematisch wird es, wenn günstige Lösungen vollständige Barrierefreiheit versprechen, aber nur einzelne technische Aspekte prüfen oder oberflächlich korrigieren.
Digitale Barrierefreiheit betrifft nicht nur den Quellcode. Sie betrifft Struktur, Gestaltung, Redaktion, Dokumente, Videos, Formulare, Navigation, Kontaktmöglichkeiten, Betriebs- und Qualitätssicherung. Ein barrierefreier Auftritt entsteht deshalb nicht durch eine einzelne Maßnahme, sondern durch ein Zusammenspiel vieler Entscheidungen.
Kann Barrierefreiheit auch günstig sein?
Ja, Barrierefreiheit darf günstig sein. Sie darf aber nicht beliebig sein. Günstig ist gut, wenn damit gemeint ist: effizient geplant, mit Standards umgesetzt und sinnvoll geprüft. Viele gute Maßnahmen kosten wenig, wenn sie von Anfang an mitgedacht werden.
Teuer wird Barrierefreiheit oft dann, wenn sie nachträglich eingebaut werden soll. Das World Wide Web Consortium (W3C) empfiehlt, Barrierefreiheit dauerhaft in den Webproduktionsprozess zu integrieren und entsprechende Aktivitäten nicht nur einmalig, sondern wiederholt umzusetzen. Auch der W3C Business Case beschreibt, dass frühe Berücksichtigung von Barrierefreiheit Kosten senken kann.
Warum nachträgliche Korrekturen teuer werden
Wenn Barrierefreiheit erst kurz vor Veröffentlichung geprüft wird, sind viele Entscheidungen bereits getroffen. Das Design ist abgenommen, Komponenten sind programmiert, Inhalte sind eingepflegt und technische Abhängigkeiten sind festgelegt. Werden dann grundlegende Barrieren gefunden, müssen häufig mehrere Ebenen angepasst werden.
Typische Beispiele:
Ein Designsystem enthält Farben mit zu geringem Kontrast. Dann betrifft die Korrektur nicht nur eine Seite, sondern alle Buttons, Links, Hinweise, Karten, Statusmeldungen und grafische Bedienelemente des gesamten Auftrittes.
Videos wurden ohne Untertitel produziert. Dann müssen Transkription, Timing, Korrektur und Einbindung nachträglich organisiert werden.
Die wichtigste Kostenregel lautet deshalb: Je später Barrierefreiheit integriert wird, desto teurer werden grundlegende Korrekturen.
Kostenfreie Tools: hilfreich, aber begrenzt
Kostenfreie Werkzeuge sind ein guter Einstieg. Sie helfen dabei, Barrieren sichtbar zu machen und erste Prüfungen selbst durchzuführen. Dazu gehören Bookmarklets, Kontrastprüfer, Browser-Erweiterungen, Screenreader und automatisierte Testwerkzeuge.
Solche Werkzeuge können zum Beispiel zeigen:
ob Bilder beschriftet sind
ob Kontraste ausreichend sind
ob der Tastaturfokus sichtbar ist
Aber solche Tools prüfen nicht alles. Sie erkennen häufig nur technische Teilaspekte. Ob ein Alternativtext inhaltlich sinnvoll ist, ob eine Fehlermeldung verständlich ist oder ob eine Navigation logisch aufgebaut ist, muss fachlich bewertet werden.
Was automatische Tests leisten und was nicht
Automatisierte Tests sind sinnvoll, solange ihr sie richtig einordnet. Sie liefern schnelle Hinweise, unterstützen die Entwicklung und helfen, wiederkehrende Fehler früh zu erkennen.
Sie sind besonders hilfreich für:
regelmäßige Prüfungen während der Entwicklung
schnelle Erstanalysen einzelner Seiten
technische Regressionstests
Sie reichen nicht aus für die Bewertung, ob ein Prozess für Nutzende wirklich funktioniert.
Automatisierte Tests auf Basis von ACT Rules können nützliche Hinweise liefern. ACT steht für „Accessibility Conformance Testing“. Gemeint sind einheitliche Prüfregeln, mit denen bestimmte Barrieren möglichst nachvollziehbar gefunden werden können.
Solche Regeln helfen, damit verschiedene Werkzeuge ähnliche Elemente prüfen und Ergebnisse besser vergleichbar werden. Sie erkennen aber nur einen Teil der Barrieren. Ob ein Hinweis wirklich ein Barrierefreiheitsproblem ist und wie schwer dieses Problem wiegt, muss, fachlich bewertet werden.
Eine endgültige Einschätzung kann daher nur gemeinsam mit manuellen Prüfungen, Tastaturtests, Screenreader-Tests und Erfahrung erfolgen.
Im Folgenden findet ihr eine Liste kostenlos nutzbarer Werkzeuge, diese Ansammlung ist keine komplette Auflistung aller verfügbaren Tools. Sie ist nur eine Übersicht.
Kontrastprüfer und Farbsimulation
WebAIM Contrast Checker
Funktion: Prüfung von Textkontrasten und grafischen Bedienelementen
Mit dem WebAIM Contrast Checker könnt Ihr Vordergrund- und Hintergrundfarben eingeben oder über eine Farbauswahl bestimmen. Das Werkzeug berechnet das Kontrastverhältnis und zeigt an, ob die WCAG-Anforderungen für normalen Text, großen Text sowie grafische Bedienelemente erfüllt werden.
Colour Contrast Analyser
Funktion: Kontrastprüfung auf dem gesamten Bildschirm
Der kostenlose Colour Contrast Analyser von Vispero eignet sich besonders für Inhalte, die nicht direkt im Browser geprüft werden. Dazu gehören Anwendungen, PDF-Dokumente, Präsentationen, Screenshots oder Designentwürfe. Mit einer Pipette könnt Ihr Vordergrund- und Hintergrundfarben direkt vom Bildschirm aufnehmen. Das Werkzeug enthält außerdem eine Simulation verschiedener Farbsehschwächen.
Coblis Color Blindness Simulator
Funktion: Simulation von Farbsehschwächen
Mit dem Coblis Color Blindness Simulator könnt Ihr Bilder hochladen und simulieren, wie sie bei unterschiedlichen Formen von Farbsehschwäche wahrgenommen werden könnten. Das Werkzeug kann dabei helfen, problematische Farbkombinationen zu erkennen. Es ersetzt jedoch keine Messung des tatsächlichen Kontrastverhältnisses.
Browser-Erweiterungen für automatisierte Prüfungen
WAVE Browser Extension
Browser: Chrome, Firefox und Edge
Funktion: Automatische Analyse einzelner Seiten
WAVE Browser Extension prüft den aktuell dargestellten Webauftritt direkt im Browser. Das Werkzeug zeigt unter anderem Fehler, Warnungen, Alternativtexte, Überschriften, Formularbeschriftungen, Kontraste und ARIA-Hinweise an. Die Browser-Erweiterung verarbeitet die Inhalte lokal.
ARC Toolkit
Browser: Chrome und Firefox
Funktion: Prüfung einzelner Seiten nach WCAG-Anforderungen
Das kostenlose ARC Toolkit analysiert einzelne Seiten und zeigt mögliche Barrieren sowie Hinweise zur Behebung an. Es unterstützt unter anderem die Prüfung von Kontrasten, Formularen, Struktur und Quellcode.
Accessibility Insights for Web
Browser: Chrome und Edge
Funktion: Schnelle automatische und angeleitete Prüfungen
Accessibility Insights for Web bietet mit dem FastPass einen schnellen Einstieg in die Prüfung eines Webauftritts. Zusätzlich stehen angeleitete Prüfungen und visuelle Hilfen zur Verfügung. Das Werkzeug kann dabei unterstützen, häufige technische Barrieren sowie Probleme bei Tastaturbedienung und Fokusführung zu erkennen.
Bookmarklets von Tollwerk
Bookmarklets sind kleine Programme, die als Lesezeichen im Browser gespeichert werden. Sie werden auf dem aktuell geöffneten Webauftritt ausgeführt und können bestimmte Strukturen oder Eigenschaften sichtbar machen. Eine zusätzliche Browser-Erweiterung ist nicht erforderlich. Unter folgendem Link geht es zu den Bookmarklets von Tollwerk.
Landmarks
Funktion: Prüfung der Seitenbereiche
Das Bookmarklet hebt Landmark-Bereiche wie Hauptinhalt, Navigation, Kopfbereich und Fußbereich hervor. Damit könnt Ihr schnell prüfen, ob der Webauftritt sinnvoll gegliedert ist und ob mehrere gleichartige Bereiche unterscheidbar benannt wurden.
Images
Funktion: Prüfung von Bildern und Alternativtexten
Das Bookmarklet zeigt Bilder und die zugehörigen Alternativtexte an. Es kann dabei helfen, fehlende oder auffällige Alternativtexte zu erkennen. Ob ein Alternativtext den Inhalt und Zweck eines Bildes richtig beschreibt, müsst Ihr anschließend selbst bewerten.
Show Tabfocus
Funktion: Prüfung des Tastaturfokus
Das Bookmarklet unterstützt die Prüfung des sichtbaren Tastaturfokus. Beim Navigieren mit der Tabulatortaste könnt Ihr nachvollziehen, welches Element gerade fokussiert ist und ob der Fokus deutlich dargestellt wird.
Was macht Qualität aus?
Qualität in der digitalen Barrierefreiheit entsteht nicht durch ein einzelnes Prüfprotokoll. Qualität entsteht, wenn Barrierefreiheit in allen Phasen mitgedacht wird.
Konkrete Anforderungen
Barrierefreiheit muss schon Ausschreibungs- und Vergabeunterlagen und Projektzielen stehen. Unklare Formulierungen wie „barrierefrei nach aktuellen Standards“ reichen oft nicht aus. Besser sind konkrete Anforderungen:
Welche Standards gelten?
Welche Seitentypen oder Prozesse werden geprüft?
Welche Dokumente, Videos oder Formulare gehören dazu?
Gute technische Umsetzung bedeutet nicht, möglichst viel Spezialtechnik zu verwenden. Häufig ist das Gegenteil richtig: Native HTML-Elemente, klare Struktur, sinnvolle Beschriftungen und robuste Bedienbarkeit sind die Grundlage.
Ein gutes Beispiel ist die Tastaturbedienung. Eine Webseite muss auch ohne Maus bedienbar sein. Nutzende müssen beispielsweise mit Tab-, Enter-, ESC- und Pfeil-Tasten Elemente erreichen und bedienen können. Eine durchgängige Tastaturbedienbarkeit ist eine Grundvoraussetzung für digitale Barrierefreiheit.
Kritisch sind Lösungen, die Barrierefreiheit nur über eine zusätzliche Oberfläche herstellen wollen, ohne die eigentlichen Barrieren im Webauftritt zu beheben. Dadurch kann der Webauftritt für viele Nutzende weiterhin problematisch bleiben.
Mehr zur sauberen Technik erfahrt Ihr im Leitfaden WAI-ARIA der BFIT.
Verständliche Inhalte
Barrierefreiheit ist nicht nur Technik. Auch Inhalte müssen verständlich, gut strukturiert und sinnvoll beschriftet sein. Auftritt kann technisch fehlerfrei sein und trotzdem schwer nutzbar bleiben.
Typische Qualitätsfragen sind:
Sind Überschriften hierarchisch logisch aufgebaut?
Sind Linktexte verständlich?
Wird Fachsprache erklärt?
Sind Anleitungen klar?
Sind Fehlermeldungen konkret?
Sind Pflichtfelder eindeutig gekennzeichnet?
Gerade bei Formularen entscheidet die Verständlichkeit darüber, ob Nutzende den Prozess abschließen können.
Prüfung mit echten Nutzungsszenarien
Eine gute Prüfung fragt nicht nur: Gibt es einen Fehler im Code? Sie fragt: Können Menschen den Webauftritt tatsächlich nutzen?
Dazu gehören Tests mit:
Tastatur
Screenreader
Vergrößerung
hohen Kontrasten
mobilen Ansichten
Sprachsteuerung, wenn relevant
verschiedenen Browsern
realistischen Aufgaben
Tests mit Nutzenden, mit und ohne Beeinträchtigung
Eine sinnvolle Aufgabe ist zum Beispiel nicht: „Prüfe die Startseite“. Besser ist: „Finde ein bestimmtes Formular, fülle es aus, korrigiere einen Fehler und sende es ab.“ So zeigt sich, ob Barrierefreiheit in einem echten Nutzungspfad funktioniert.
Nachhaltiger Betrieb
Ein Webauftritt ist nie fertig. Neue Inhalte, neue Komponenten, neue PDFs, neue Videos und neue Kampagnen können jederzeit neue Barrieren erzeugen. Qualität braucht deshalb Prozesse.
Dazu gehören:
Schulungen für Redaktion und Entwicklung
barrierefreie Vorlagen
Prüfungen vor Veröffentlichung
wiederkehrende Stichproben
klare Zuständigkeiten
Auswertung von Rückmeldungen über den Feedback-Mechanismus
Pflege der Erklärung zur Barrierefreiheit
Dokumentation von Entscheidungen
Ein Feedback-Mechanismus hilft dabei, dass Barrieren von Nutzenden gemeldet werden können. So können reale Barrieren im Nutzungsprozess gut erkannt werden. Er soll leicht erreichbar, barrierefrei nutzbar und mit klaren Kontaktinformationen verbunden sein.
Checkliste für Auftraggeber
Die folgende Checkliste verdichtet die gesetzlichen Anforderungen, die W3C-Evaluationslogik und die aktuellen BFIT-Vergabeempfehlungen zu einem operativen Raster für Auftraggebende. Sie ist bewusst streng formuliert, weil gerade unklare Prüffragen später zu teuren Missverständnissen führen könnten.
Bereich
Prüfpunkte
Maßnahmen
Freigabekriterium
Planung
Sind Zielgruppen, Rechtsgrundlagen, Standards und Verantwortlichkeiten benannt?
Dokumentenreview, Projektstart-Workshop
Freigabe erst, wenn Projektparameter schriftlich feststehen
Beschaffung
Enthält die Leistungsbeschreibung verbindliche Kriterien zur Barrierefreiheit? Sind Dokumente, Medien, Drittkomponenten und Vertragslaufzeit einbezogen?
Vergabeunterlagen prüfen
Veröffentlichung der Vergabeunterlagen nur, wenn Anforderungen und Nachweise vollständig geregelt sind
Design
Sind Kontraste, Fokus, Tastaturkonzept, Struktur und verständliche Inhalte früh geprüft?
Designreview, Prototypentest, einfache Checks
Keine Designfreigabe bei bekannten Basisverstößen
Entwicklung
Gibt es entwicklungsbegleitende Tests und dokumentierte Korrekturen?
Kombination aus automatisierten und manuellen Tests
Feature gilt erst als fertig, wenn Accessibility-Kriterien mitgeprüft wurden
Kernprozesse
Sind zentrale Nutzungsfunktionen definiert, etwa Suche, Formular, Login, Checkout, Antrag oder Kontakt?
Aufgabenbasierte Tests mit assistiven Technologien
Abnahme nur, wenn Kernprozesse funktionsfähig und dokumentiert sind
Audit
Sind Prüfumfang, Testumgebung, Tools, assistive Technologien, Fundstellen und Schweregrade im Bericht ausgewiesen?
Unabhängiger Audit oder qualitätsgesicherter Expertentest
Bericht muss reproduzierbar, nachvollziehbar und ticketfähig sein
Nutzerbeteiligung
Wurden Menschen mit Beeinträchtigungen sinnvoll und vergütet einbezogen?
Review der Testplanung und Ergebnisse
Kritische Befunde müssen in Maßnahmenplan und Nachprüfungen eingehen
Abnahme
Sind alle kritischen Befunde behoben oder mit verbindlichem Maßnahmenplan terminiert?
Nachprüfung des ursprünglichen Berichts
Keine Abnahme ohne Nachweis der Behebung zentraler Barrieren
Laufender Betrieb
Gibt es Feedbackmöglichkeit, Zuständigkeit, Update-Prüfung und regelmäßige Überprüfung?
Monitoring, Ticketauswertung, Erneutes Audit bei Änderungen
Der Auftritt gilt nur dann als stabil, wenn Änderungen nicht ungeprüft live gehen
Warnzeichen für schlechte Angebote
Nicht jedes günstige Angebot ist schlecht. Aber es gibt deutliche Warnzeichen.
Vorsicht ist geboten, wenn:
vollständige Barrierefreiheit durch ein einziges Plugin versprochen wird
nur ein automatisierter Scan angeboten wird
keine manuelle Prüfung vorgesehen ist
keine Prüfung mit Tastatur erfolgt
keine Prüfung mit Screenreader vorgesehen ist
nur die Startseite geprüft wird
Formulare, Dokumente und Videos nicht erwähnt werden
keine Nachprüfung enthalten ist
keine konkreten Fehlerbeschreibungen geliefert werden
keine priorisierten Empfehlungen enthalten sind
keine Aussage zur Prüfmethode gemacht wird
keine Qualifikation oder Erfahrung erkennbar ist
Barrierefreiheit als einmalige Reparatur verkauft wird
keine erkennbare Fachkompetenz, keine Referenzen und keine klaren Liefergegenstände wie Prüfberichte, Mängellisten oder Umsetzungspläne genannt wird.
Wie ihr Kosten senkt, ohne Qualität zu verlieren
Kosten lassen sich vor allem dort senken, wo Barrierefreiheit nicht jedes Mal neu erfunden werden muss. Wenn Anforderungen, Vorlagen, Komponenten, Prüfwege und Zuständigkeiten klar sind, wird die Umsetzung planbarer. Das kann die Qualität erhöhen und zugleich verhindern, dass dieselben Fehler immer wieder entstehen.
Barrierefreiheit früh einplanen
Legt Anforderungen an Barrierefreiheit bereits in der Konzeptphase fest. Das betrifft nicht nur die technische Umsetzung, sondern auch Gestaltung, Redaktion, Beschaffung, Qualitätssicherung und spätere Pflege.
Früh geklärt werden sollte zum Beispiel:
Welche Anforderungen gelten für den Webauftritt?
Welche zentralen Nutzungsszenarien müssen besonders gut funktionieren?
Welche Formulare, Downloads und interaktiven Funktionen sind besonders wichtig?
Wer prüft Barrierefreiheit während der Umsetzung?
Wer entscheidet, ob ein Ergebnis abgenommen werden kann?
Wie werden Barrieren dokumentiert und nachverfolgt?
Je früher diese Fragen geklärt werden, desto geringer kann das Risiko werden, dass später grundlegende Layouts, Komponenten oder Prozesse neu gebaut werden müssen.
Designsysteme barrierefrei aufbauen
Ein barrierefreies Designsystem kann helfen, Qualität und Kosten besser zu steuern. Wenn Buttons, Formularfelder, Menüs, Hinweise, Fehlermeldungen, Dialoge, Karten, Akkordeons oder Suchfunktionen einmal sauber gestaltet, umgesetzt und geprüft sind, können sie wiederverwendet werden.
Wichtig ist: Ein Designsystem ist nur dann hilfreich, wenn Barrierefreiheit darin verbindlich berücksichtigt wird. Es sollte also nicht nur Farben und Abstände beschreiben, sondern auch Tastaturbedienung, Fokuszustände, Beschriftungen, Fehlermeldungen, ARIA-Einsatz, Kontraste und Verhalten bei Vergrößerung.
Standardlösungen bevorzugen
Standardlösungen sind oft robuster, günstiger und besser unterstützt als selbst gebaute Sonderlösungen. Das gilt besonders für HTML-Elemente.
Ein <button>-HTML-Element bringt bereits viele Eigenschaften mit, die für Barrierefreiheit wichtig sind. Es ist mit der Tastatur erreichbar, hat eine erwartbare Rolle und wird von assistiven Technologien in der Regel korrekt erkannt. Ein selbst gebautes Element aus <div>, zusätzlicher Rolle und JavaScript muss diese Eigenschaften erst nachbilden. Dabei entstehen häufig Fehler.
Das bedeutet nicht, dass eigene Komponenten nie sinnvoll wären. Sie sollten aber nur eingesetzt werden, wenn es dafür einen guten Grund gibt und wenn Bedienung, Semantik und Fokusführung sorgfältig geprüft werden. So können Entwicklungsaufwand, Fehlerrisiken und spätere Nachbesserungen reduziert werden.
Redaktion schulen
Viele Barrieren entstehen nicht im Quellcode, sondern im redaktionellen Alltag. Dazu gehören unklare Linktexte, fehlende oder schlechte Alternativtexte, nicht strukturierte Überschriften, lange unübersichtliche Textblöcke, fehlerhafte Tabellen oder nicht barrierefreie PDF-Dokumente.
Kurze, regelmäßige Schulungen können hier besonders wirksam sein. Sie müssen nicht immer umfangreich sein. Oft reichen wiederkehrende Lerneinheiten zu konkreten Aufgaben.
Redaktionelle Schulungen können Kosten senken, weil Fehler gar nicht erst entstehen. Gleichzeitig verbessert sich die Qualität des gesamten Webauftritts, weil Inhalte verständlicher und besser nutzbar werden.
Vorlagen und Textbausteine nutzen
Vorlagen und Textbausteine sorgen dafür, dass wiederkehrende Inhalte nicht jedes Mal neu geschrieben oder technisch neu aufgebaut werden müssen. Solche Vorlagen ersetzen keine Prüfung im Einzelfall. Sie können aber eine einheitliche Grundqualität sichern und den Aufwand im Alltag deutlich verringern.
Automatisierte Tests einbinden
Automatisierte Tests sollten früh in Entwicklungsprozesse eingebunden werden. Sie finden nicht alle Barrieren, können aber helfen, wiederkehrende technische Fehler früh zu erkennen.
Besonders sinnvoll sind automatische Tests, wenn sie regelmäßig laufen, etwa bei neuen Komponenten, vor der Veröffentlichung oder in Entwicklungsprozessen. Dann werden einfache Fehler nicht erst am Ende gefunden, sondern bereits während der Umsetzung.
Wichtig bleibt: Automatisierte Tests liefern Hinweise, aber keine vollständige Bewertung. Sie können nicht zuverlässig beurteilen, ob ein Alternativtext inhaltlich passend ist, ob ein Linktext im Kontext verständlich ist oder ob ein Formularablauf für Nutzende wirklich nachvollziehbar funktioniert.
Manuelle Prüfung gezielt einsetzen
Manuelle Prüfungen sind aufwendiger als automatische Tests. Sie gezielt dort eingesetzt werden, wo sie den größten Nutzen bringen.
Gerade zentrale Bereiche, wie Navigation und Formulare entscheiden oft darüber, ob Nutzende ein Anliegen selbstständig erledigen können. Wenn hier Barrieren bestehen, ist der Schaden meist größer als bei selten aufgerufenen Unterseiten.
Rückmeldungen ernst nehmen
Rückmeldungen von Nutzenden sind keine Störung. Sie sind ein wichtiges Qualitätsinstrument. Ein gut auffindbarer und barrierefreier Feedback-Mechanismus hilft, reale Probleme zu erkennen, die in internen Prüfungen übersehen wurden.
Menschen mit Beeinträchtigungen einbinden
Tests mit Menschen mit Beeinträchtigungen können besonders wertvoll sein, wenn zentrale Prozesse geprüft werden sollen. Sie zeigen, wie ein Webauftritt in echten Nutzungssituationen funktioniert.
Wichtig ist, solche Tests richtig einzuordnen. Einzelne Rückmeldungen ersetzen keine vollständige fachliche Prüfung. Sie können aber Probleme sichtbar machen, die automatische Tests und rein technische Prüfungen nicht erfassen. Dazu gehören unverständliche Abläufe, unerwartete Fokuswechsel, unklare Hilfetexte oder Prozesse, die zwar technisch bedienbar sind, aber praktisch schwer nutzbar bleiben.
Beschaffung mitdenken
Barrierefreiheit sollte in Beschaffung und Vergabe verbindlich berücksichtigt werden. Wenn Anforderungen erst nach Vertragsschluss formuliert werden, kann die Nachbesserung schwierig und teuer werden.
Deshalb sollten Ausschreibungen und Verträge möglichst klar benannt werden. Das kann helfen, Qualität bereits vor der Umsetzung abzusichern. Gleichzeitig wird für Dienstleister klarer, welche Leistung erwartet wird.
Regelmäßige Nachprüfung einplanen
Barrierefreiheit ist kein Zustand, der einmal erreicht und dann dauerhaft gesichert ist. Inhalte ändern sich, Systeme werden aktualisiert, neue Komponenten kommen hinzu und Redaktionen werden neu besetzt. Durch regelmäßige Nachprüfung kann Barrierefreiheit Teil des normalen Betriebs werden. Das ist meist nachhaltiger, als nur alle paar Jahre eine große Prüfung durchzuführen.
Fazit
Barrierefreiheit darf günstig sein. Sie darf aber nicht oberflächlich sein.
Der beste Weg zu effizienterer Barrierefreiheit ist nicht die günstigste Einzellösung, sondern eine kluge Gesamtstrategie. Wenn ihr Barrierefreiheit früh plant, Standards nutzt, Inhalte verständlich erstellt, zentrale Komponenten sauber umsetzt und gezielt prüft, spart ihr langfristig Geld und verbessert die Qualität eurer Webauftritte.
Günstige Lösungen sind dann problematisch, wenn dadurch Scheinsicherheit entsteht. Gute Barrierefreiheit erkennt ihr daran, dass sie nachvollziehbar geplant, fachkundig umgesetzt, real geprüft und dauerhaft gepflegt wird. Genau dann ist Barrierefreiheit nicht nur pflichtmäßig umgesetzt, sondern ein Qualitätsmerkmal digitaler Angebote.
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Warum ist eine Erklärung zur Barrierefreiheit wichtig?
Die Erklärung zur Barrierefreiheit ist ein wesentlicher Bestandteil der digitalen Barrierefreiheit und nicht nur eine gesetzliche Anforderung, sondern auch ein zentraler Bestandteil von Inklusion. Sie zeigt transparent auf, welche Inhalte und Funktionen einer Webseite oder mobilen Anwendung barrierefrei gestaltet sind und wo noch Verbesserungen notwendig sind. Eine gut formulierte und aktuelle Erklärung hilft Nutzenden, zu verstehen, welche Barrieren noch bestehen und wie sie Unterstützung erhalten können.
Hinter der Erklärung zur Barrierefreiheit stehen verschiedene Gesetze:
Die EU-Richtlinie 2016/2102, die die Anforderungen an die Barrierefreiheit öffentlicher Websites und mobiler Anwendungen festlegt
Der Durchführungsbeschluss der EU-Kommission 2018/1523, der Regelungen und Muster für die Erklärung zur Barrierefreiheit bereitstellt
Die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0), welche die EU-Richtlinie in Deutschland umsetzt
Das Behindertengleichstellungsgesetz (BGG), das die Grundlage für die BITV 2.0 bildet und die Gleichstellung von Menschen mit Behinderungen stärkt.
In den Bundesländern gelten eigene gesetzliche Bestimmungen. Dieses Dokument zeigt beispielhaft, wie die Erklärung zur Barrierefreiheit richtig und vollständig erstellt werden sollte.
Relevante Anforderungen (gemäß BITV 2.0 § 7)
Die Erklärung zur Barrierefreiheit muss umfassend und klar verständlich bewerten, inwieweit die Webseite oder mobile Anwendung mit den Anforderungen zur Barrierefreiheit vereinbar ist. Wenn Teile nicht vollständig barrierefrei sind, müssen diese benannt und die Gründe dafür angegeben werden.
Die Erklärung zur Barrierefreiheit ist in einem barrierefreien und maschinenlesbaren Format zu veröffentlichen.
Eine Verlinkung zur Erklärung zur Barrierefreiheit erfolgt an hervorgehobener Stelle auf der Startseite und ist auf jeder Unterseite vorhanden.
Die Erklärung zur Barrierefreiheit ist als solche erkennbar.
Der Geltungsbereich der Erklärung wird genannt (Name der öffentlichen Stelle, Name der Webseite).
Es wird auf die Rechtsgrundlage verwiesen. Es erfolgte eine Angabe, inwieweit die Anforderungen an die Barrierefreiheit erfüllt wurden (vollständig vereinbar / teilweise vereinbar / nicht vereinbar).
Nicht barrierefreie Inhalte, sofern vorhanden, sind aufgeführt.
Falls Alternativen zu nicht barrierefreien Inhalten verfügbar sind, sollten diese in der Barrierefreiheitserklärung vermerkt werden.
Optionale Inhalte beispielsweise Maßnahmen, die über die Mindestanforderungen hinausgehen oder die für die Beseitigung von Barrieren ergriffen werden sollen, sind angegeben.
Die verwendete Prüfmethode (Selbstprüfung oder Dritte) wird benannt.
Das Datum der Erstellung oder der letzten Aktualisierung ist vorhanden und das Datum ist nicht älter als ein Jahr.
Ein Feedback-Mechanismus mit der Möglichkeit für Betroffene, elektronisch Kontakt aufzunehmen, ist angegeben und beschrieben.
Kontaktangaben der Zuständigen Stelle (bei der öffentlichen Stelle) für barrierefreie Zugänglichkeit sind benannt.
Das Durchsetzungsverfahren / Beschwerdeverfahren ist beschrieben und der Kontakt zur Durchsetzungsstelle / Beschwerdestelle ist aufgeführt.
Umsetzung einer barrierefreien Erklärung zur Barrierefreiheit
Eine vollständige und korrekte Barrierefreiheitserklärung sollte in folgende Bestandteile gegliedert werden:
Erreichbarkeit der Erklärung
Es sollte ein gut sichtbarer Link zur Erklärung auf der Startseite platziert werden, und es ist sicherzustellen, dass die Erklärung auf jeder Unterseite auffindbar ist.
Beschreibung des Geltungsbereichs
Anzugeben ist, welche Institution oder Webseite durch die Erklärung abgedeckt wird.
Die gesetzlichen Grundlagen, die für die Erklärung zur Barrierefreiheit relevant sind, wie z. B. die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung), sollten angegeben werden.
Bewertung der Barrierefreiheitsanforderungen
Es sollte erläutert werden, in welchem Umfang die Anforderungen erfüllt, sind: vollständig, teilweise oder nicht vereinbar.
Nicht barrierefreie Inhalte aufführen
Bereiche oder Inhalte, die nicht barrierefrei sind, sollten aufgezählt und es sollte erklärt werden, warum diese Anforderungen aktuell nicht erfüllt werden. Zusätzlich kann hier erklärt werden, wie und wann bestehende Barrieren behoben werden.
Vermerk zu Alternativen für nicht barrierefreie Inhalte
Verfügbare Alternativen zu nicht barrierefreien Inhalten sollten in der Barrierefreiheitserklärung angegeben werden (z. B. Beschreibungen, Transkripte, ergänzende Audioinhalte).
Prüfmethode angeben
Es sollte erklärt werden, ob die Webseite durch Selbstprüfung oder durch eine externe Stelle geprüft wurde.
Aktualitätsdatum angeben
Das Datum der Erstellung oder der letzten Überprüfung der Erklärung sollte angegeben werden. Diese sollte nicht älter als ein Jahr sein. Um Änderungen im Inhalt, bei der Technologie oder bei rechtlichen Vorgaben zu berücksichtigen.
Feedback-Mechanismus und Kontaktstellen
Den Nutzenden sollte eine Möglichkeit zur Rückmeldung geboten werden. Außerdem sollten die Kontaktinformationen der verantwortlichen Stelle angegeben werden, damit Nutzende bei Fragen oder Anregungen zur Barrierefreiheit direkt Kontakt aufnehmen können.
Es sollte über das Beschwerdeverfahren informiert und die Kontaktinformationen der zuständigen Durchsetzungsstelle angegeben werden, falls Nutzende eine Beschwerde einreichen möchten.
Klare und verständliche Sprache verwenden
Die Erklärung sollte einfach und verständlich formuliert werden, damit sie für alle Nutzenden – unabhängig von deren Fähigkeiten nachvollziehbar ist.
Zugänglichkeit der Erklärung sicherstellen
Es sollte darauf geachtet werden, dass die Erklärung selbst barrierefrei zugänglich ist. Es ist empfehlenswert, den Link zur Barrierefreiheitserklärung an einer gut auffindbaren Stelle zu platzieren, idealerweise im oberen Bereich der Seite. Falls eine Service-Navigation vorhanden ist, bietet es sich an, den Link dort einzufügen. Dies erleichtert den Nutzenden den schnellen Zugang zur Erklärung.
Regionale Anforderungen beachten
Je nach Bundesland können zusätzliche Anforderungen gelten. Es sollte sichergestellt werden, dass spezifische regionale Vorgaben bekannt sind.
Optionale Angaben für die Erklärung zur Barrierefreiheit gemäß BITV 2.0 § 7
Erläuterung der Bemühungen um eine bessere digitale Barrierefreiheit:
Absicht, ein höheres Maß an Barrierefreiheit zu erreichen als gesetzlich vorgeschrieben.
Abhilfemaßnahmen für nicht barrierefreie Inhalte, inklusive eines Zeitrahmens für deren Umsetzung.
Förmliche Bestätigung der Barrierefreiheitserklärung (administrativ oder politisch).
Datum der Veröffentlichung der Website und/oder mobilen Anwendung.
Datum der letzten Aktualisierung der Website und/oder mobilen Anwendung nach wesentlicher inhaltlicher Überarbeitung.
Link zu einem Bewertungsbericht, falls verfügbar, insbesondere bei vollständiger Vereinbarkeit der Website oder mobilen Anwendung.
Zusätzliche telefonische Hilfe für Menschen mit Behinderungen sowie Unterstützung für Nutzer von assistiven Technologien.
Weitere Inhalte, die als angemessen erachtet werden.
Barrierefreiheitserklärung des Beispielamts
Diese Erklärung gilt für die Website des Beispielamts, erreichbar unter http://www.beispielamt.de.Sie umfasst alle Inhalte und Funktionen der Webseite, soweit diese nicht anderweitig angegeben sind.
Als öffentliche Stelle im Sinne der RICHTLINIE (EU) 2016/2102 sind wir bemüht, unsere Webauftritte im Einklang mit den Bestimmungen des Behindertengleichstellungsgesetzes des Bundes (BGG) sowie der Barrierefreien-Informationstechnik-Verordnung (BITV 2.0) zur Umsetzung der RICHTLINIE (EU) 2016/2102 barrierefrei zugänglich zu machen.
Bewertung der Barrierefreiheitsanforderungen
Die Webseite des Beispielamts erfüllt die Anforderungen der BITV 2.0 teilweise. Viele Inhalte sind bereits barrierefrei gestaltet, einige Bereiche weisen jedoch noch Barrieren auf, die derzeit in Bearbeitung sind.
Aktuell sind einige PDF-Dokumente und interaktive Grafiken nicht vollständig barrierefrei. Auch folgende Bereiche weisen Barrieren auf:
Videos ohne Untertitel oder Audiodeskriptionen.
Tabellen, die nicht korrekt für Screenreader ausgezeichnet sind.
Formulare mit fehlenden oder unzureichenden Beschriftungen.
Inhalte von Drittanbietern, die nicht barrierefrei gestaltet sind.
Diese Barrieren sind aufgrund technischer Einschränkungen oder externer Ressourcen noch nicht behoben. Wir arbeiten daran, diese Inhalte in Q3 2025 barrierefrei anzubieten.
Die Website wurde einer internen Selbstprüfung durch das Beispielamt unterzogen. Eine externe Überprüfung ist für das kommende Jahr geplant.
Aktualitätsdatum
Diese Erklärung wurde am 25. Oktober 2024 erstellt und zuletzt am 25. Oktober 2024 überprüft. Die Webseite wurde 01.Dezember.2020 erstellt und am 25. Oktober.2024 zuletzt aktualisiert.
Zusätzliche Bemühungen um Barrierefreiheit
Das Beispielamt hat sich zur Bereitstellung einer umfassenden und transparenten Barrierefreiheitserklärung verpflichtet. Hierzu wurden einige fakultative Maßnahmen eingeführt, die über die gesetzlichen Mindestanforderungen hinausgehen und zur Verbesserung der digitalen Zugänglichkeit beitragen sollen.
Zusätzliche telefonische Hilfe für Menschen mit Behinderungen Für Menschen mit Behinderungen bietet das Beispielamt zusätzliche Unterstützung in Form einer telefonischen Beratung an. Sollten Fragen zur Barrierefreiheit der Website bestehen oder Probleme beim Zugang auftreten, können sich Nutzende direkt telefonisch an uns wenden. Diese Unterstützung soll sicherstellen, dass auch diejenigen, die Schwierigkeiten bei der Nutzung unserer digitalen Angebote haben, die erforderliche Hilfe erhalten.
Kontakt für zusätzliche Hilfe:
Telefon: 01234 / 567890
Veröffentlichung eines Bewertungsberichts
Das Beispielamt veröffentlicht einen Bewertungsbericht zur Barrierefreiheit der Website, um Transparenz zu schaffen und Nutzenden einen detaillierten Einblick in die Barrierefreiheit unseres Webauftritts zu bieten.
Barrieren melden: Kontakt zu den Ansprechpartnern
Sollten Ihnen Barrieren auffallen oder benötigen Sie weitere Informationen zur Barrierefreiheit, können Sie uns über die E-Mail-Adresse barrierefreiheit@beispielamt.de kontaktieren. Wir sind bemüht, Ihre Anfragen zeitnah zu beantworten.
Durchsetzungsverfahren
Sollten Sie mit der Bearbeitung Ihrer Anfrage unzufrieden sein, können Sie sich an die Schlichtungsstelle nach § 16 BGG wenden. Die Schlichtungsstelle BGG hat die Aufgabe, bei Konflikten zum Thema Barrierefreiheit zwischen Menschen mit Behinderungen und öffentlichen Stellen des Bundes eine außergerichtliche Streitbeilegung zu unterstützen.
Das Schlichtungsverfahren ist kostenlos. Es muss kein Rechtsbeistand eingeschaltet werden.
Weitere Informationen zum Schlichtungsverfahren und den Möglichkeiten der Antragstellung erhalten Sie unter www.schlichtungsstelle-bgg.de.
Checkliste für die Erstellung einer Erklärung zur Barrierefreiheit
Erreichbarkeit der Erklärung
Platzierung eines gut sichtbaren Links zur Erklärung auf der Startseite und auf jeder Unterseite der Website.
Empfehlung: Integration in die Service-Navigation, falls vorhanden.
Beschreibung des Geltungsbereichs
Benennung der Institution oder Webseite, für die die Erklärung gilt.
Klare Angaben zu den abgedeckten Inhalten und Funktionen.
Rechtsgrundlage angeben
Verweis auf relevante gesetzliche Grundlagen wie die EU-Richtlinie 2016/2102, das Behindertengleichstellungsgesetz (BGG) und dieBarrierefreie-Informationstechnik-Verordnung (BITV 2.0) oder die jeweiligen landesrechtlichen Vorschriften
Bewertung der Barrierefreiheitsanforderungen
Angabe, in welchem Umfang die Anforderungen erfüllt sind (vollständig, teilweise, nicht vereinbar).
Gründe für die Nichtvereinbarkeit nennen.
Nicht barrierefreie Inhalte
Auflistung der Bereiche oder Inhalte, die nicht barrierefrei sind.
Begründung, warum diese Anforderungen aktuell nicht erfüllt werden.
Vermerk zu Alternativen
Alternativen für nicht barrierefreie Inhalte nennen
Prüfmethode angeben
Angabe, ob die Prüfung der Website durch eine interne Selbstprüfung oder durch eine externe Stelle erfolgt ist.
Aktualitätsdatum
Angabe des Datums der Erstellung oder der letzten Überprüfung der Erklärung.
Erklärung sollte nicht älter als ein Jahr sein.
Feedback-Mechanismus und Kontaktstellen
Bereitstellung einer Möglichkeit zur Rückmeldung für Nutzende.
Kontaktinformationen der verantwortlichen Stelle für Fragen oder Anregungen zur Barrierefreiheit.
Durchsetzungsverfahren
Information zum Beschwerdeverfahren.
Kontaktinformationen der zuständigen Durchsetzungsstelle angeben.
Klare und verständliche Sprache verwenden
Die Erklärung sollte so formuliert sein, dass sie für alle Nutzenden leicht verständlich ist.
Optionale Angaben
Die Erklärung kann durch weitere freiwillige Maßnahmen ergänzt werden, um Transparenz und Unterstützung über die gesetzlichen Mindestanforderungen hinaus zu gewährleisten.
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Was ist der Feedback-Mechanismus?
Der Feedback-Mechanismus ist Bestandteil der Erklärung zur Barrierefreiheit. In § 12b Abs. 2 Behindertengleichstellungsgesetz (BGG) und § 7 Abs. 2 der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) ist auf Bundesebene geregelt, dass der Feedback-Mechanismus von jeder Seite eines Webauftritts oder innerhalb der Navigation einer App unmittelbar zugänglich und einfach zu benutzen sein soll. Rückmeldungen helfen öffentlichen Stellen, Barrieren zu identifizieren und zeitnah zu beheben.
Der Mechanismus ist rechtlich in § 7 Absatz 2 der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) geregelt und soll von jeder Seite eines Webauftritts oder in der Navigation einer App leicht erreichbar sein. Rückmeldungen über den Mechanismus helfen öffentlichen Stellen, Barrieren zu identifizieren und zeitnah zu beheben.
Warum ist der Feedback-Mechanismus wichtig?
Für Betroffene: Er bietet Menschen mit Behinderungen die Möglichkeit, Barrieren aktiv zu melden und so die Nutzung von Webauftritten und Apps zu verbessern.
Für die Allgemeinheit: Jede gemeldete Barriere trägt dazu bei, digitale Angebote inklusiver zu machen – was allen zugutekommt. Die Erklärung zur Barrierefreiheit ist in einem barrierefreien und maschinenlesbaren Format zu veröffentlichen.
Wie sieht ein Feedback-Mechanismus nach der BITV aus?
Gemäß § 7 Absatz 2 der BITV 2.0 soll der Feedback-Mechanismus folgende Anforderungen erfüllen:
Sichtbarkeit: Er soll leicht auffindbar und direkt zugänglich sein über die „Erklärung zur Barrierefreiheit“, die auf jeder Seite des oder in der Navigation der App verlinkt ist.
Nutzbarkeit: Der Feedback-Mechanismus soll barrierefrei, klar und einfach zu verwenden sein.
Kontaktinformationen: Angaben zur zuständigen öffentlichen Stelle, einschließlich E-Mail-Adresse oder Kontaktformular, müssen enthalten sein.
Rückmeldung: Die öffentliche Stelle muss zeitnah auf Anfragen reagieren – abhängig von den jeweiligen gesetzlichen Vorgaben, innerhalb von 2 bis 6 Wochen.
Durchsetzungsverfahren: Informationen zur zuständigen Durchsetzungs-/ Schlichtungsstelle müssen in der Erklärung zur Barrierefreiheit verfügbar sein, falls die öffentliche Stelle nicht reagiert oder die Barriere nicht behoben wird.
Wie funktioniert der Feedback-Mechanismus?
Barriere melden:
Beschreibt die Barriere so genau wie möglich:
Wo tritt die Barriere auf?
Welches Betriebssystem, welchen Browser und welche Hilfsmittel werden genutzt? (z. B. Screenreader mit Version)
Reaktion der öffentlichen Stelle:
Die öffentliche Stelle muss auf die Meldung reagieren. Die Antwortfrist ist nach den jeweiligen gesetzlichen Vorgaben des Landes geregelt.
Durchsetzungs-/ Schlichtungsstelle kontaktieren:
Erhaltet ihr keine Antwort oder wird die Barriere nicht behoben, könnt ihr euch an die zuständige Durchsetzungs-/ Schlichtungsstelle wenden. Diese prüft den Fall und setzt sich mit der öffentlichen Stelle auseinander.
Wie verläuft ein Schlichtungs– oder Durchsetzungsverfahren?
Meistens läuft das Schlichtungsverfahren schriftlich ab. Die Schlichtungsstelle prüft, ob der Antrag zulässig ist und kontaktiert die öffentliche Stelle. Sie kann sich innerhalb eines Monats zu dem Antrag äußern. Eine schlichtende Person wirkt auf eine Einigung hin und kann dazu auch einen Vorschlag unterbreiten.
Das Schlichtungsverfahren endet entweder mit einer Einigung der Beteiligten oder mit einer Mitteilung, dass keine Einigung erreicht werden konnte.
In den Ländern verläuft das Durchsetzungsverfahren ähnlich. Dort ist oft Voraussetzung, dass ihr vorher den Feedback-Mechanismus genutzt habt. Schaut in die Erklärung zur Barrierefreiheit: hier müssen das Verfahren im eigenen Land und die zuständige Durchsetzungsstelle genannt sein. Auf dieser Website findet ihr eine Übersicht der Durchsetzungsstellen: https://lbit.hessen.de/ds/stellen.
Wie setzt man einen guten Feedback-Mechanismus auf Webauftritten um?
Ein gut gestalteter Feedback-Mechanismus schafft Vertrauen und fördert die Zusammenarbeit zwischen Nutzenden und öffentlichen Stellen. Mit der richtigen Umsetzung stellt ihr sicher, dass euer Webauftritt barrierefrei bleibt und kontinuierlich verbessert wird.
Sichtbarkeit:
Der Mechanismus muss leicht auffindbar sein. Platziert diesen an prominenter Stelle.
Benutzerfreundlichkeit:
Erstellt ein intuitives und einfach zu nutzendes Kontaktformular oder bietet eine direkte E-Mail-Adresse an.
Strukturierte Abfrage:
Sorgt dafür, dass Nutzende relevante Informationen wie Betriebssystem, Browser und Hilfsmittel angeben können. Dies erleichtert die Analyse der gemeldeten Barriere.
Verfügbarkeit von Kontaktinformationen:
Gebt die Kontaktdaten der zuständigen Stelle für Barrierefreiheit an, wie z. B. E-Mail-Adresse, Telefonnummer und Postanschrift.
Zeitnahe Rückmeldung:
Stellt sicher, dass Anfragen innerhalb der vorgeschriebenen Frist (abhängig von den gesetzlichen Vorgaben) bearbeitet werden.
Beispiel für einen guten Feedback-Mechanismus
Platzierung und Verlinkung:
In der Menüleiste des Webauftritts:
Inhalte des Kontaktformulars:
Name: (Optional)
E-Mail-Adresse: (Pflichtfeld)
Beschreibung der Barriere: Freitextfeld, in dem Nutzer den Ort und die Art der Barriere beschreiben können.
Technische Details: Dropdown-Menü oder Checkboxen für:
Betriebssystem (z. B. Windows, iOS, Android)
Browser (z. B. Chrome, Firefox, Safari)
Eingesetzte Hilfsmittel (z. B. Screenreader mit Version)
Dateiupload: Option, Screenshots oder Dateien zur Verdeutlichung hochzuladen.
Beispieltext für Feedback-Seite:
„Wir möchten unseren Webauftritt so barrierefrei wie möglich gestalten. Sollten Sie auf Barrieren stoßen, bitten wir Sie, uns diese über das folgende Formular zu melden. Wir bearbeiten Ihre Anfrage schnellstmöglich und informieren Sie über die Ergebnisse.
Checkliste für einen guten Feedback-Mechanismus
Platzierung und Verlinkung:
Ist der Feedback-Mechanismus auf jeder Seite erreichbar (z. B. über die „Erklärung zur Barrierefreiheit“)?
Ist die Verlinkung klar und auffällig, z. B. in der Navigation oder im Footer?
Benutzerfreundlichkeit:
Ist das Kontaktformular leicht verständlich und klar strukturiert?
Werden Pflichtfelder deutlich markiert?
Ist die Nutzung barrierefrei möglich?
Relevante Abfragen:
Können Nutzende die gemeldete Barriere genau beschreiben (Ort, Art der Barriere)?
Werden technische Details abgefragt (Betriebssystem, Browser, Hilfsmittel)?
Gibt es eine Möglichkeit, unterstützende Dateien hochzuladen?
Kontaktinformationen:
Sind die Kontaktdaten der zuständigen Stelle klar angegeben (E-Mail-Adresse, Telefonnummer)?
Ist die Durchsetzungs-/ Schlichtungsstelle für Beschwerden verlinkt?
Reaktion und Rückmeldung:
Sind interne Prozesse definiert, um Rückmeldungen innerhalb der gesetzlichen Frist zu bearbeiten?
Werden Nutzende über den Fortschritt oder die Lösung der gemeldeten Barriere informiert?
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Einleitung
Die Deutsche Gebärdensprache (DGS) ist seit 2002 im Bundesgleichstellungsgesetz anerkannt. Es ist wissenschaftlich erwiesen, dass es sich dabei um eine eigenständige, visuell-gestische Sprache mit eigener Grammatik, Ausdrucksweise und kultureller Bedeutung handelt. Für gehörlose und schwerhörige Menschen (Deaf Community) ist sie die Erstsprache und somit das zentrale Kommunikationsmittel im Alltag und im gesellschaftlichen Leben, um Informationen, Emotionen und komplexe Inhalte zu verstehen und mitzuteilen.
Im digitalen Raum spielt Gebärdensprache eine entscheidende Rolle für echte Barrierefreiheit. Nur wenn Inhalte auch in Gebärdensprache angeboten werden, können gehörlose Menschen öffentliche Informationen, Dienstleistungen und Angebote gleichberechtigt nutzen. Genau hier setzt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) an: Sie verpflichtet öffentliche Stellen, zentrale Informationen ihrer Webauftritte auch in DGS bereitzustellen.
Auf der Startseite eines Internet- oder Intranetauftritts sind gemäß § 4 der BITV 2.0 folgende Erläuterungen in DGS bereitzustellen:
Informationen zu den wesentlichen Inhalten des Webauftritts,
Hinweise zur Navigation,
eine Erläuterung der wesentlichen Inhalte der Erklärung zur Barrierefreiheit,
sowie Hinweise auf weitere in diesem Webauftritt vorhandene Informationen in Deutscher Gebärdensprache.
In Anhang 2, Teil 1 der BITV 2.0 findet sich Vorgaben, wie diese Informationen bereitgestellt werden sollen. Diese Regelung gilt sowohl für öffentliche als auch für interne Webauftritte (Intranets) von Behörden.
Gebärdensprachevideos sind somit ein wesentlicher Bestandteil einer inklusiven digitalen Kommunikation. Sie schaffen Sichtbarkeit, fördern Verständnis und ermöglichen Teilhabe für alle.
Zu beachten ist, dass in der Anlage 2 der Barrierefreie Informationstechnik Verordnung (BITV) 2.0 technisch zum Teil veraltete Vorgaben enthalten sind. Aus Sicht der gehörlosen Community besteht daher die Forderung, die BITV hier zu aktualisieren oder alternativ auf eine dynamisch gepflegte Webseite zu verweisen, auf der der technische Stand der Anforderungen flexibel und rasch an neue Entwicklungen angepasst werden kann.
Welche Inhalte müssen Gebärdensprachevideos enthalten?
Erläuterungen zu den Hauptinhalten: Stellt die wesentlichen Angebote oder Themen Eures Webauftritts in einem kurzen Überblick vor. Erläutert, was die Seite bietet, an wen sie sich richtet und welche Informationen besonders wichtig sind. Diese Seite ist für die Deaf Community besonders relevant.
Hinweise zur Navigation: Zeigt in Gebärdensprache, wie Nutzende sich auf eures Webauftritts zurechtfinden können: Wo sich Menüs, Suchfunktionen, Formulare oder Hilfebereiche befinden und wie man dorthin gelangt.
Erklärungen zu Formularen und interaktiven Inhalten: Beschreibt, wie Formulare genutzt oder interaktive Funktionen bedient werden können, zum Beispiel Terminbuchung, Online-Antrag oder Feedbackformular.
Kontakt und Unterstützung: Gebt an, wie Ihr erreichbar seid, per E-Mail, Telefon, Gebärdensprach-Videotelefonie oder Rückruffunktion und welche weiteren Unterstützungsangebote oder barrierefreien Hilfen es gibt.
Erklärung zur Barrierefreiheit: Fasst die wichtigsten Punkte eurer Erklärung zur Barrierefreiheit in DGS zusammen, insbesondere Hinweise auf bestehende Barrieren und Kontaktwege für Feedback.
Hinweis auf weitere Inhalte in DGS: Informiert über zusätzliche Gebärdensprachvideos, die auf anderen Unterseiten verfügbar sind. Die Erklärung zur Barrierefreiheit ist in einem barrierefreien und maschinenlesbaren Format zu veröffentlichen.
Wie gestalte ich Gebärdensprachevideos?
Die BITV definiert gestalterische und technische Mindestanforderungen, damit Gebärdensprachvideos gut wahrnehmbar und technisch zugänglich sind. Wenn diese Anforderungen nicht erfüllt sind, kann sogar eine Ausgrenzung statt Inklusion entstehen.
Achtet bei der Produktion Eurer Videos auf folgende Punkte:
Sichtbarer Gebärdenraum: Für gute Sichtbarkeit müssen Hände, Arme, Kopf und Oberkörper vollständig erkennbar sein.
Kleidung: dunkel, einfarbig, kontrastreich zur Haut. Schmuck oder gemusterte Kleidung ist zu vermeiden.
Hintergrund: ruhig, statisch, nicht rein weiß oder schwarz. Optional mit Logo gestaltet.
Beleuchtung: gleichmäßig, Schatten vermeiden(wichtig), Mindestkontrast von 4.5:1 zwischen Person und Hintergrund.
Format: 16:9, Auflösung mindestens 1080p, 25 Bilder pro Sekunde, flüssige Wiedergabe ohne Ruckeln.
Dateiformat: MP4 (H.264) oder gleichwertig.
Videolänge: ideal 4–6 Minuten;Textlänge zwischen 200 und 350 Wörtern und längere Inhalte in mehrere Abschnitte aufteilen.Die angegebene Videolänge gilt pro Video.
Das Informationsangebot in DGS muss auf der Startseite eines Webauftritts eindeutig als Icon oder Schriftzug gekennzeichnet sein.
Das bedeutet:
Auf Eurer Startseite, meist im Servicebereich oder im Kopfbereich der Seite sollte sich ein klar erkennbarer Link zu den Inhalten in DGS befinden.
Der Link trägt die Bezeichnung „Gebärdensprache“ und wird zusätzlich mit dem offiziellen Symbol für die Deutsche Gebärdensprache (DGS-Logo) versehen.
Das Piktogramm oder der Schriftzug hilft Nutzerinnen und Nutzern, das Angebot schnell zu erkennen und unmittelbar aufzurufen. Ihr findet es in Anlage 2, Teil 1 BITV 2.0.
Achtet darauf, dass:
der Link gut sichtbar platziert ist (z. B. im Service- oder Kopfmenü),
das DGS-Logo kontrastreich und eindeutig erkennbar ist.
Struktur und Anzahl der Videos
Erfahrungsgemäß ist es besser, mehrere kurze Videos statt eines langen Films zu veröffentlichen. So bleiben die Informationen übersichtlich, gezielt abrufbar und sind bei einzelnen Aktualisierungen der Inhalte auch besser auszutauschen.
Wir empfehlen: Mindestens drei Videos mit klar abgegrenzten Themen, zum Beispiel:
Überblick über den Webauftritt.
Navigation und Nutzung der Seite (Einbindung von Screenshots wird empfohlen).
Kontaktmöglichkeiten und Erklärung zur Barrierefreiheit.
Jedes Video sollte mit einem eindeutigen Titel, einer kurzen Beschreibung und einem sichtbaren Vorschaubild versehen sein. Damit wird sichergestellt, dass Nutzende gezielt die Informationen finden, die sie benötigen, und sich leicht im Angebot orientieren können. Dies kann mit Untertiteln versehen werden, damit es barrierefrei für unterschiedliche Zielgruppen verfügbar ist.
Wen kann ich beauftragen?
Wählt für die Produktion Eurer Gebärdensprachvideos qualifizierte Dienstleister, die die DIN EN ISO 17100 („Anforderungen an Übersetzungsdienstleistungen“) erfüllen.
Achtet darauf, dass:
taube Dolmetschende (native signers) beteiligt sind,
alle Mitwirkenden über eine anerkannte Ausbildung im Gebärdensprachdolmetschen verfügen (Bachelor, Diplom oder staatliche Prüfung),
der Produktionsprozess ein Vier-Augen-Prinzip vorsieht (eine Überprüfung durch eine zweite Fachperson).
Nachweis der Fachkunde durch Referenzen der letzten 2 Jahre.
Auflösung mindestens 1080p, klare Sicht auf Hände und Gesicht.
Einheitliche Gestaltung, ggf. Untertitel oder Vertonung optional.
Klare Beleuchtung, ruhiger Hintergrund, gut sichtbares Logo
Gebärdensprach-Avatare: Chancen und Grenzen
Mittlerweile werden auch Gebärdensprach-Avatare (computer-animierte Gebärdensprach-Darstellende) für die Erstellung von Gebärdensprachvideos angeboten. Hierbei sind aktuell jedoch die deutlichen Einschränkungen der Technologie Insbesondere im Hinblick auf eine barrierefreie Kommunikation in DGS zu beachten.
Potenziale
Avatare könnten zukünftig eine schnelle und flexible Lösung bieten, insbesondere wenn kurze Informationen oder automatisiert erzeugte Texte in Gebärdensprache übertragen werden sollen.
Grenzen und kritische Aspekte
Studien zeigen: Viele gehörlose Nutzerinnen und Nutzer bewerten die Verständlichkeit, Natürlichkeit und Qualität von Avataren nicht als ausreichend. Beispielsweise wurden Bewegungen als „robotisch“, Mimik und Mundbild als unzureichend beschrieben. Studie: 5-Toward-an-evaluation-model-for-signing-avatars.pdf
Gebärdensprachen haben eine komplexe visuell-gestische Struktur (Hände, Arme, Körper, Mimik, Gesichtsausdruck), die von Avataren bisher nicht vollumfänglich korrekt dargestellt wird. Eine unsaubere Darstellung kann die Informationsvermittlung deutlich beeinträchtigen und Nutzerinnen und Nutzer verunsichern.
Auch bei Avatar-Firmen müssen taube qualifizierte Dolmetscher:innen involviert werden. Bislang sagt die Community, dass Sie nicht ausreichend einbezogen wurden.
Empfehlungen für den Einsatz
Nutzt Avatare derzeit nicht als Ersatz für qualifizierte gebärdensprachliche Dolmetschleistungen, sondern allenfalls als ergänzendes Angebot.
Wenn Avatare eingesetzt oder geplant werden, müssen diese klar im Projekt verankert werden: Es muss eine Evaluation durch gehörlose Nutzerinnen und Nutzer erfolgen (z. B. Verständlichkeitstests, Nutzertests, Fokusgruppen).
Achtet darauf, dass die Avatare die Mindestanforderungen für DGS-Qualität erfüllen, insbesondere gute Mimik, Mundbild, korrekte Gebärdenrhythmen, passende Geschwindigkeit und korrekte Gebärdenwahl. Wenn diese Anforderungen nicht erfüllt sind, kann sogar eine Ausgrenzung statt Inklusion entstehen.
Nach unserer Wahrnehmung ist die Akzeptanz solcher Avatare in der Deaf-Community bislang gering. Viele gehörlose Nutzerinnen und Nutzer empfinden die Darstellungen als sprachlich unnatürlich, mimisch unpräzise oder kulturell nicht authentisch. Aus diesem Grund empfehlen wir, auf den Einsatz von Gebärdensprach-Avataren derzeit zu verzichten. Solange diese Technologien weder die sprachliche Vielfalt der Deutschen Gebärdensprache noch deren Ausdrucksqualität zuverlässig wiedergeben können, stellen sie keinen gleichwertigen Ersatz für menschliche Dolmetschende oder native Signer dar.
Checkliste für Gebärdensprachvideos
Zentrale Inhalte des Webauftritts sind in DGS erklärt.
Mindestens drei thematisch getrennte Videos vorhanden.
Taube Übersetzer:innen sind qualifiziert.
Gebärdende Person ist klar, vollständig und kontrastreich sichtbar.
Beleuchtung gleichmäßig, keine Schatten, neutraler Hintergrund.
Videos erfüllen Auflösung (≥ 1080p) und Framerate (≥ 25 fps).
DGS-Pikotogram oder Schriftzug ist auf der Webseite vorhanden und kontrastreich.
Videos sind auf der Startseite und in der Barrierefreiheitserklärung verlinkt.
Untertitel und Transkript sind verfügbar.
Automatisierte Avatar-Lösungen werden kritisch geprüft, aber nicht als Ersatz genutzt.
Anbieter erfüllt DIN EN ISO 17100 und legt Referenzen vor.
Inhalte wurden mit gehörlosen Nutzerinnen und Nutzern getestet.
Dieser Text kann auch als PDF Datei heruntergeladen werden.
KI-Technologien
KI-Technologien können Nutzende dabei unterstützen, digitale und analoge Informationen wahrzunehmen, zu verstehen oder zu bedienen. Im Mittelpunkt stehen KI-gestützte Hilfsmittel, die Barrieren ausgleichen können. Gemeint sind hier nicht allgemeine KI-Werkzeuge zum Schreiben, Zusammenfassen oder Recherchieren.
Dazu gehören zum Beispiel Apps, die Bilder beschreiben, Texte vorlesen, Sprache live verschriftlichen, nicht beschriftete Schaltflächen auf Webauftritten erklären oder Informationen aus der Umgebung über eine Kamera erfassen.
KI-gestützte Angebote können im Alltag eine große Hilfe sein. Sie können blinden oder sehbehinderten Menschen Bilder, Dokumente oder Umgebungen beschreiben. Sie können gehörlosen oder schwerhörigen Menschen Gespräche live als Text anzeigen. Sie können Menschen mit Lernschwierigkeiten, Dyslexie oder Konzentrationsproblemen helfen, Informationen leichter aufzunehmen, indem sie Texte vorlesen.
Wichtig ist aber: KI ist kein Ersatz für barrierefreie Gestaltung. Ein nicht beschrifteter Button bleibt ein Barrierefreiheitsmangel, auch wenn ein Screenreader oder eine App versucht, ihn nachträglich zu erklären. KI kann im Einzelfall helfen, eine Barriere zu überbrücken. Sie macht den Webauftritt selbst aber nicht barrierefrei.
Auch das KI-Tool selbst muss barrierefrei nutzbar sein. Ein Hilfsmittel darf nicht neue Hürden erzeugen, etwa durch eine nicht bedienbare App, unbeschriftete Schaltflächen, fehlende Tastaturbedienung, unzureichende Kontraste oder nicht zugängliche Ergebnisanzeigen.
Welche KI-gestützten Hilfen gibt es bereits?
Die vorgestellten Tools sind nicht vollständig und die Tools sind nicht gänzlich auf Barrierefreiheit geprüft. Der Leitfaden gilt lediglich als Hilfestellung und Einstieg. Die Links zu den einzelnen Anwendungen können am Ende des Dokuments gefunden werden.
Bilder, Texte und Umgebung beschreiben
Apps wie Seeing AI, Google Lookout oder Be My Eyes unterstützen blinde und sehbehinderte Menschen beim Erkennen von Texten, Objekten, Bildern oder Alltagssituationen.
Seeing AI eignet sich vor allem für typische Alltagssituationen: einen Brief lesen, Verpackungen erkennen, Produkte unterscheiden, Fotos beschreiben oder kurze Texte erfassen. Die App ist dabei besonders niedrigschwellig, weil sie auf dem Smartphone genutzt werden kann und verschiedene Erkennungsfunktionen in einer Anwendung bündelt. Microsoft beschreibt Seeing AI als kostenlose App, die die Welt um Nutzende herum beschreibt und für blinde und sehbehinderte Menschen entwickelt wurde.
Google Lookout verfolgt einen ähnlichen Ansatz, ist aber besonders eng mit Android verbunden. Die App kann beim Lesen von Texten und Dokumenten helfen, Informationen aus der Umgebung erfassen und Gegenstände oder Lebensmittel einordnen. Google beschreibt Lookout ausdrücklich als App für blinde und sehbehinderte Menschen. Sie soll unter anderem beim Lesen, Sortieren von Post oder Wegräumen von Einkäufen unterstützen.
Be My Eyes unterscheidet sich von rein automatischen Lösungen, weil hier KI und menschliche Unterstützung zusammenkommen. Nutzende können sich per Live-Video mit Freiwilligen verbinden oder KI-gestützte Bildbeschreibungen nutzen. Das ist wichtig, weil nicht jede Situation allein durch KI zuverlässig gelöst werden kann. Wenn eine Beschreibung unklar ist oder eine Entscheidung wichtig wird, kann menschliche Unterstützung weiterhin sinnvoll oder notwendig sein. Be My Eyes beschreibt die eigene App als Angebot, das blinde oder sehbehinderte Menschen mit Freiwilligen, Unternehmen und KI verbindet. Be My Eyes verbindet Nutzende mit Freiwilligen, die mehr als 185 Sprachen sprechen; die Verbindung erfolgt vorrangig anhand der eingestellten Hauptsprache und, falls dort niemand verfügbar ist, anhand einer hinterlegten Zweitsprache.
In der Praxis können solche Apps viel Selbstständigkeit ermöglichen. Sie helfen, wenn ein Bild keinen Alternativtext hat, ein Papierdokument nicht digital vorliegt, ein Schild nicht gelesen werden kann oder ein Gegenstand nicht eindeutig erkennbar ist. Sie können auch eine Brücke sein, wenn ein Webauftritt, eine App oder ein Dokument schlecht barrierefrei umgesetzt wurde. Diese Brücke darf aber nicht mit echter Barrierefreiheit verwechselt werden.
Kritisch bleibt die Verlässlichkeit der Ergebnisse. KI kann Inhalte falsch erkennen, Text unvollständig erfassen oder eine Situation missverstehen. Gerade bei Medikamenten, Lebensmitteln mit Allergiehinweisen, Verträgen, Geld, Wegbeschreibungen, Gefahrenstellen oder rechtlich relevanten Informationen sollten Nutzende den Ergebnissen nicht ungeprüft vertrauen. Wenn ihr das Ergebnis nicht selbst überprüfen könnt, braucht es bei wichtigen Entscheidungen eine zweite Quelle, etwa eine menschliche Unterstützung oder ein anderes Hilfsmittel.
Webauftritte und Apps besser verstehen
Auch Screenreader und ergänzende Screenreader-Erweiterungen integrieren zunehmend KI-Funktionen.
JAWS bietet mit Picture Smart AI eine Funktion, mit der Fotos, Diagramme und andere visuelle Inhalte analysiert und als Beschreibung ausgegeben werden können. Dies kann besonders in Situationen geeignet sein, in denen Nutzende auf Bilder, Grafiken oder andere visuelle Elemente ohne ausreichende Alternativbeschreibung stoßen. Die Beschreibung wird anschließend im JAWS Results Viewer angezeigt.
Für NVDA gibt es Erweiterungen wie AI Content Describer. Dieses Add-on kann Fokusobjekte, Bedienelemente, Bilder, den gesamten Bildschirm oder eine Kameraszene beschreiben. Nach Angaben der Add-on-Beschreibung werden dafür KI-Modelle mit Bildverarbeitung genutzt. Gleichzeitig weist die Beschreibung darauf hin, dass die ausgegebenen Beschreibungen nicht immer vollständig korrekt sein müssen.
Auch Microsoft Narrator erhält KI-gestützte Funktionen. Microsoft erklärt, dass Nutzende mit einer Tastenkombination eine Beschreibung des fokussierten Bildes oder des gesamten Bildschirms anfordern können. Dabei öffnet sich Copilot mit dem Bild und Nutzende können eine eigene Frage zur Beschreibung stellen. Microsoft weist darauf hin, dass das Bild erst geteilt wird, wenn Nutzende die Beschreibung aktiv auslösen.
KI kann in solchen Fällen eine zusätzliche Orientierung geben. Dennoch bleibt Vorsicht nötig: Die KI erkennt nicht immer den tatsächlichen Zweck eines Elements. Ein Symbol kann falsch interpretiert werden. Ein Button kann anhand seiner Position beschrieben werden, ohne dass die eigentliche Funktion sicher erkannt wird. KI kann eine Barriere überbrücken, sie behebt sie nicht. Wenn ein Button keinen zugänglichen Namen hat, bleibt der Webauftritt mangelhaft. Wenn ein Diagramm nicht beschrieben ist, bleibt die Information unvollständig. Wenn die Seitenstruktur unklar ist, kann KI höchstens eine Annäherung liefern.
Gespräche live verschriftlichen
Für gehörlose und schwerhörige Menschen können KI-gestützte Transkriptionsdienste Sprache live in Text umwandeln. Solche Funktionen können in persönlichen Gesprächen, Besprechungen, Veranstaltungen, Arztterminen, Unterrichtssituationen oder digitalen Meetings unterstützen.
Ava bietet Live-Untertitel und Transkription für Gespräche, Meetings und weitere Situationen an. Nach Angaben von Ava kombiniert der Dienst KI-gestützte Transkription mit menschlicher Unterstützung, um höhere Genauigkeit zu erreichen. Ava richtet sich ausdrücklich an gehörlose und schwerhörige Menschen.
Google Live Transcribe & Sound Notifications macht gesprochene Sprache und Umgebungsgeräusche über Android-Geräte zugänglicher. Google beschreibt die App als Unterstützung für alltägliche Gespräche und Geräuschinformationen für gehörlose und schwerhörige Menschen. Die gesprochenen Wörter erscheinen auf dem Bildschirm des Android-Geräts.
Die Qualität hängt stark von der Umgebung ab. Hintergrundgeräusche, Dialekte, Fachbegriffe, mehrere gleichzeitig sprechende Personen oder schlechte Mikrofone können die Erkennungsqualität deutlich verschlechtern.
Für informelle Gespräche kann eine automatische Transkription oft ausreichen. Für wichtige Veranstaltungen, Schulungen, Gerichts-, Verwaltungs-, Medizin- oder Prüfkontexte sollte sie nicht unkritisch als alleinige Lösung eingesetzt werden. Hier können professionelle Untertitelung, Schriftdolmetschung oder Gebärdensprachdolmetschung notwendig sein.
Texte vorlesen und leichter zugänglich machen
Vorlesefunktionen und Text-to-Speech-Anwendungen wandeln geschriebene Inhalte in gesprochene Sprache um. Das kann für blinde und sehbehinderte Menschen, Nutzende mit Dyslexie, ADHS, Konzentrationsproblemen, Lernschwierigkeiten oder hoher Leseermüdung hilfreich sein. Nicht jedes Vorlesewerkzeug ist automatisch KI. KI wird aber zunehmend genutzt, um Stimmen natürlicher klingen zu lassen, gedruckte Texte per OCR zu erfassen oder ergänzende Funktionen bereitzustellen.
Speechify liest nach eigenen Angaben Bücher, PDFs, Dokumente und Webauftritte vor. Enthalten sind unteranderem Funktionen wie Vorlesen, Geschwindigkeitseinstellung, Texthervorhebung und das Erfassen von gedruckten Inhalten per Foto.
Für Nutzende mit Lese- und Schreibschwierigkeiten gibt es weitere Werkzeuge wie Read&Write. Der Anbieter beschreibt Funktionen wie Text-to-Speech, vereinfachte Textumformulierung und visuelle Wörterbücher, um Lesen, Schreiben und Lernen zu unterstützen.
Solche Werkzeuge können Texte zugänglicher machen, weil sie verschiedene Zugangswege ermöglichen. Nutzende können Inhalte hören statt zu lesen, gleichzeitig mitlesen, die Geschwindigkeit anpassen oder störende Seitenelemente ausblenden. Das hilft nicht nur Menschen mit Behinderungen, sondern auch in Alltagssituationen, etwa bei Müdigkeit, hoher Informationsdichte oder langer Bildschirmarbeit.
Die Grenzen liegen vor allem bei der Qualität des Ausgangsmaterials. Eine Vorlesefunktion kann nur das sinnvoll ausgeben, was technisch und inhaltlich zugänglich vorhanden ist. Ein schlecht strukturiertes PDF, eine falsche Lesereihenfolge, ein gescannter Text mit OCR-Fehlern, fehlende Überschriften oder nicht ausgezeichnete Tabellen bleiben problematisch. Auch Sprachwechsel können falsch vorgelesen werden, wenn die Sprache nicht korrekt ausgezeichnet ist. Vorlesen ist daher keine Reparatur für mangelhafte Dokumente oder Webauftritte. Es kann unterstützen, aber es ersetzt keine echte Struktur, keine korrekten Überschriften, keine barrierefreien Tabellen, keine richtige Sprachauszeichnung und keine verständliche Sprache.
Smart Glasses und Kamera-Hilfen
Smart Glasses und tragbare Kamera-Hilfen verbinden Kamera, Mikrofon, Lautsprecher und KI-Funktionen. Sie können Nutzenden Informationen über ihre Umgebung geben, Texte vorlesen, Objekte erkennen, Gespräche als Text anzeigen oder bei der Orientierung unterstützen. Neben Ray-Ban Meta gibt es weitere Anbieter, die solche Funktionen entweder für den allgemeinen Markt oder gezielt als Assistenztechnologie entwickeln.
Die Envision Glasses und Ally Solos Glasses richten sich ausdrücklich an blinde und sehbehinderte Menschen. Sie sollen dabei helfen, Menüs zu lesen, Umgebungen zu erkennen, Gegenstände oder Personen zu beschreiben und Informationen per Sprachinteraktion abzufragen.
Für gehörlose und schwerhörige Nutzende sind andere Funktionen besonders relevant. XRAI Glass bietet eine KI-gestützte Lösung für Live-Untertitel und Übersetzung in Echtzeit. Gespräche können damit als Text angezeigt werden. Das kann in Besprechungen, Veranstaltungen oder lauten Umgebungen hilfreich sein, ersetzt aber keine qualitativ gesicherte Untertitelung oder Dolmetschung, wenn diese erforderlich ist.
Besonders kritisch sind Kamera-Brillen beim Datenschutz. Sie erfassen nicht nur die Umgebung, sondern möglicherweise auch andere Personen, private Räume, Dokumente, Bildschirminhalte oder Gespräche. Je stärker ein System Fotos, Video, Ton oder Standortdaten an Cloud-Dienste überträgt, desto wichtiger sind klare Informationen zu Einwilligung, Speicherung, Verarbeitung und Löschung.
Smart Glasses können Nutzenden mehr Orientierung und Selbstständigkeit geben. Sie ersetzen aber weder barrierefreie digitale Angebote noch eine bewusste Prüfung von Datenschutz, Zuverlässigkeit und Grenzen der KI.
Texte verstehen und vereinfachen
Textvereinfacherung kann Nutzende unterstützen, wenn Texte zu lang, zu fachlich, zu abstrakt oder sprachlich zu schwer sind. Besonders relevant ist das für Menschen mit Lernschwierigkeiten, kognitiven Einschränkungen, geringer Lesekompetenz, geringen Deutschkenntnissen oder hoher Leseermüdung.
Der Verainfacher ist dafür ein gutes Beispiel. Die Anwendung wurde von KOPF, HAND und FUSS entwickelt und wird als KI-gestützte Anwendung beschrieben, die Menschen mit Lernschwierigkeiten dabei unterstützt, Textinhalte besser zu verstehen. Dabei geht es nicht nur darum, einen schweren Text in leichtere Sprache zu übertragen. Der Verainfacher arbeitet dialogisch: Nutzende können Texte, Screenshots oder Fotos erfassen lassen und erhalten Erklärungen und Wiederholungen, bis der Inhalt besser verstanden wird. Die Anwendung wurde gemeinsam mit der Zielgruppe entwickelt.
SUMM AI ist ein KI-basiertes Tool, das Texte in Leichte und Einfache Sprache übersetzt. Das Angebot richtet sich besonders an öffentliche Stellen, Verwaltungen und Organisationen, die Inhalte systematisch verständlicher bereitstellen wollen. SUMM AI beschreibt das Tool als KI-basiertes Übersetzungswerkzeug für Leichte und Einfache Sprache.
capito.ai unterstützt beim Schreiben verständlicher Texte, analysiert Texte in drei Sprachstufen und gibt Vorschläge zur Vereinfachung. Das Tool kann Texte auch vollautomatisch vereinfachen.
Wichtig ist außerdem die Abgrenzung zur geprüften Leichten Sprache. Leichte Sprache ist nicht einfach „ein bisschen einfacher schreiben“. Sie folgt Regeln, richtet sich besonders an Menschen mit Lernschwierigkeiten und sollte idealerweise durch Menschen aus der Zielgruppe geprüft werden.
Werden Texte automatisch in leichtere Sprache übertragen, kann die KI Fehler erzeugen. Bei wichtigen Informationen, etwa Gesundheit, Recht, Geld, Arbeit oder Behördenentscheidungen, dürfen KI-Vereinfachungen deshalb nicht ungeprüft als verbindliche Aussage verstanden werden.
Geräte mit Sprache, Blick oder weniger Bewegung bedienen
KI-gestützte Eingabehilfen können Geräte für Menschen mit motorischen Einschränkungen zugänglich machen. Das ist z. B. relevant bei Spastik, Tremor, nach Schlaganfall, bei fortschreitenden Erkrankungen wie ALS oder Multipler Sklerose sowie bei eingeschränkter Feinmotorik.
Die Apple Sprachsteuerung und der Windows-Sprachzugriff erlauben die vollständige Bedienung des Geräts per Stimme: Apps öffnen, Texte diktieren, Schaltflächen aktivieren oder navigieren, ohne Maus oder Tastatur. Beide Anbieter beschreiben die Funktionen ausdrücklich als Bedienhilfen für Menschen, die ihre Geräte nicht mit den Händen bedienen können.
Tobii Dynavox bietet Augensteuerungssysteme, in denen KI-gestützte Wortvorhersage die Eingabe per Blick beschleunigt. Auch in den Standard-Tastaturen auf iOS und Android arbeitet KI im Hintergrund: Wortvorhersage und Korrektur machen längere Texte für Menschen, die mit einem Finger, Kopfzeiger oder per Augensteuerung tippen, praktikabler.
Solche Hilfen können erhebliche Selbstständigkeit ermöglichen: längere E-Mails ohne Erschöpfung schreiben, im Beruf arbeiten oder kommunizieren, ohne auf eine zweite Person angewiesen zu sein.
Die Grenzen liegen bei Genauigkeit und Sprachunterstützung. Diktatfunktionen funktionieren auf Englisch oft besser als auf Deutsch. Sprachsteuerung versagt zudem dort, wo Sprechen körperlich anstrengend oder sozial unpassend ist. Eine zugängliche Tastatur- und Schalterbedienung sollte deshalb nicht ersetzt, sondern ergänzt werden.
Eigene Stimme erhalten und Sprache verständlich machen
KI-gestützte Sprachhilfen können Menschen mit Sprech- oder Sprachstörungen unterstützen, sich verständlich auszudrücken oder ihre Stimme zu erhalten. Das ist z . B. relevant bei ALS, fortgeschrittenem Parkinson, nach Schlaganfall, bei Cerebralparese oder nach Kehlkopfoperationen.
Voiceitt ist eine App, die nicht-standardisierte Sprache erkennt und in verständlichen Text oder synthetische Sprache umwandelt. Nach Angaben des Anbieters lernt das System die individuelle Aussprache und richtet sich an Menschen, deren Sprache von herkömmlicher Spracherkennung schlecht oder gar nicht erkannt wird. Google verfolgt mit Project Relate einen ähnlichen Ansatz für Android.
Apple bietet seit iOS 17 die Funktion „Eigene Stimme“. Nutzende können eine digitale Kopie der eigenen Stimme anlegen und mit „Live-Sprache“ verwenden: Getippter Text wird in der eigenen Stimme ausgegeben. Apple beschreibt die Funktion ausdrücklich für Menschen, deren Stimme aufgrund einer Diagnose verloren gehen kann. Spezialisierte Anbieter wie SpeakUnique bieten vergleichbare Voice-Banking-Dienste.
Solche Werkzeuge können Sprache, Identität und Selbstbestimmung schützen. Wer rechtzeitig aufnimmt, kann später mit der eigenen Stimme weiter kommunizieren, statt ausschließlich auf eine Standardstimme angewiesen zu sein.
Gebärdensprache und Schriftsprache verbinden
Für gehörlose Menschen, die Deutsche Gebärdensprache (DGS) als Erstsprache nutzen, ist Schriftsprache nicht automatisch barrierefrei. Live-Untertitel sind eine Hilfe, aber kein gleichwertiger Ersatz für Inhalte in DGS. KI wird zunehmend eingesetzt, um Laut- und Gebärdensprache aufeinander zu beziehen, mit derzeit sehr unterschiedlicher Reife.
Avatar-basierte Systeme, geben Text als animierte Gebärden aus. Solche Avatare werden in eng abgegrenzten Bereichen eingesetzt, etwa für standardisierte Durchsagen. Forschungsprojekte arbeiten daran, Gebärden aus Videoaufnahmen automatisch in Text zu überführen oder Schriftsprache in animierte Gebärden zu übersetzen.
KI-Avatare und automatische Gebärdenerkennung können in klar abgegrenzten Anwendungsfällen eine zusätzliche Information geben. Sie ersetzen keine qualifizierte DGS-Dolmetschung.
Wo liegen die Grenzen?
KI kann falsch liegen
KI-Ergebnisse können plausibel klingen und trotzdem falsch sein. Das ist besonders kritisch, wenn Nutzende die Ausgabe nicht selbst überprüfen können. Wenn eine App ein Medikament, ein Formular, einen Geldschein, ein Verkehrsschild oder einen Button falsch beschreibt, kann das direkte Folgen haben.
Eine KI kann ein Bild beschreiben, aber nicht immer den Zweck im konkreten Zusammenhang verstehen. Ein Symbol kann wie ein Papierkorb aussehen, aber tatsächlich eine andere Funktion haben. Ein Bild kann dekorativ sein, aber von der KI ausführlich beschrieben werden. Eine Schaltfläche kann visuell erkannt werden, aber nicht sicher in ihrer Funktion.
KI kann Barrieren sichtbar machen oder überbrücken. Sie ersetzt aber keine Prüfung mit Tastatur, Screenreader, Vergrößerung, Kontrastanalyse und fachlicher Bewertung. Das gilt auch für KI-gestützte Beschreibungen von Bildern, Formularen, Schaltflächen oder Seitenstrukturen.
Viele Funktionen brauchen Internet
Viele KI-Funktionen laufen online. Bilder, Tonaufnahmen, Bildschirmansichten oder andere Daten werden an einen Dienst übertragen und dort verarbeitet. Wenn keine Internetverbindung besteht, können manche Funktionen eingeschränkt oder gar nicht nutzbar sein. Für Nutzende ist es deshalb wichtig zu prüfen, ob eine Funktion offline funktioniert oder ob sie eine stabile Internetverbindung benötigt.
Wer KI als Hilfsmittel nutzt, überträgt möglicherweise besonders sensible Informationen. Dazu können gehören:
Fotos aus der Wohnung oder vom Arbeitsplatz.
Dokumente mit personenbezogenen Daten.
Gesprächsinhalte.
Bildschirmansichten aus Apps oder Webauftritten.
Standortbezogene Informationen.
Informationen über andere Personen im Umfeld.
Deshalb sollten Nutzende vor der Nutzung prüfen, welche Daten verarbeitet werden, ob die Verarbeitung lokal oder in der Cloud erfolgt, ob Inhalte gespeichert werden und ob sie für Training oder Qualitätssicherung genutzt werden. Datenschutzrechtlich sind dabei insbesondere Transparenz, Zweckbindung, Datenminimierung und Speicherbegrenzung wichtig. Der Europäische Datenschutzausschuss betont bei KI-Modellen ausdrücklich die Bedeutung von Zweckbindung und Datenminimierung, und auch der BfDI weist auf Risiken wie personenbezogene Daten, Speicherbegrenzung und mögliche Datenlecks im Produktivbetrieb hin.
KI kann helfen, ist aber oft nur der Umweg
KI kann in vielen Situationen hilfreich sein, wenn eine Anwendung, ein Webauftritt oder ein Dokument nicht barrierefrei gestaltet ist. Sie kann versuchen, einen nicht beschrifteten Button zu erklären, ein Bild zu beschreiben, einen schwierigen Text zu vereinfachen oder ein Gespräch live zu verschriften.
Trotzdem ist das meistens ein zusätzlicher Umweg. Nutzende müssen das KI-Tool öffnen, Berechtigungen erteilen, Inhalte hochladen oder erfassen, auf eine Antwort warten und anschließend bewerten, ob das Ergebnis überhaupt stimmt. Das kostet Zeit, Aufmerksamkeit und Vertrauen. Wenn die Anwendung oder der Webauftritt von Anfang an barrierefrei umgesetzt ist, geht es meist schneller, sicherer und selbstbestimmter: Ein korrekt beschrifteter Button wird direkt vom Screenreader ausgegeben, ein guter Alternativtext steht sofort bereit, ein barrierefreies Dokument hat eine nachvollziehbare Struktur und geprüfte Untertitel müssen nicht erst automatisch erzeugt werden.
KI kann Barrieren also überbrücken, aber sie ist häufig die langsamere und unsicherere Lösung. Gute Barrierefreiheit bedeutet, dass Nutzende Inhalte und Funktionen unmittelbar nutzen können, ohne zusätzliche Hilfswege, ohne unnötige Datenweitergabe und ohne raten zu müssen, ob die KI-Antwort stimmt.
Funktioniert die App mit Screenreader, Vergrößerung, Tastatur oder Sprachsteuerung?
Sind Kosten, Testphase und Abo-Modell verständlich?
Ist klar, ob die Funktion online oder offline arbeitet?
Ist erkennbar, welche Daten verarbeitet werden?
Könnt ihr Kamera, Mikrofon und Speicherzugriff gezielt steuern?
Gibt es eine Möglichkeit, Ergebnisse zu überprüfen?
Nutzt ihr die KI bei kritischen Entscheidungen nicht als einzige Informationsquelle?
Gibt es eine menschliche oder nicht KI-basierte Alternative?
Übersichtstabelle KI gestützter Hilfen
Die folgende Übersicht zeigt einige Beispiele für KI-gestützte Hilfen. Sie ist keine Empfehlung und keine Aussage darüber, ob ein Angebot vollständig barrierefrei, datenschutzkonform oder für jeden Einsatzzweck geeignet ist.
Ermöglicht die Steuerung eines Windows 11-PCs per Stimme. Nutzende können Apps öffnen, zwischen Apps wechseln, im Web surfen, E-Mails lesen und schreiben sowie Texte diktieren.
Voiceitt erkennt nicht-standardisierte Sprache und kann diese als verständlichen Text oder synthetische Sprache ausgeben. Das System lernt die individuelle Aussprache durch Training und richtet sich an Menschen, deren Sprache von herkömmlicher Spracherkennung schlecht erkannt wird.
Project Relate ist eine Android-App für Menschen mit nicht-standardisierter Sprache. Die App kann Sprache transkribieren, wiederholen oder zur Interaktion mit Google Assistant nutzt.
Mit „Eigene Stimme“ können Nutzende eine synthetische Stimme erstellen, die wie die eigene Stimme klingt. Diese Stimme kann mit „Live-Sprache“ genutzt werden.
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Wahrnehmbarkeit: Inhalte erfassbar machen
Das WCAG-Prinzip Wahrnehmbarkeit stellt sicher, dass alle Informationen und Funktionen einer digitalen Oberfläche von den Nutzenden wahrgenommen werden können, unabhängig von individuellen sensorischen Einschränkungen. Das bedeutet, Inhalte müssen sowohl visuell als auch auditiv zugänglich sein und dürfen nicht nur mit einem einzigen Sinn wahrgenommen werden. Dieses Prinzip betrifft insbesondere Menschen mit Sehbeeinträchtigung, blinde Menschen, Menschen mit Hörbeeinträchtigung, kognitiven Einschränkungen sowie ältere Menschen mit altersbedingtem Nachlassen der Sinneswahrnehmung.
Warum ist Wahrnehmbarkeit so wichtig?
Ohne wahrnehmbare Inhalte bleibt ein Zugang zur digitalen Information vollständig verwehrt. Nutzende von Screenreadern, brauchen z. B. Alternativtexte für Bilder, strukturierte Informationen und die Möglichkeit, Text an individuelle Bedürfnisse anzupassen. Videos mit Ton aber ohne Untertitel oder Webauftritte mit schlechtem Kontrast können zentrale Informationen unzugänglich machen.
Was ist bei der Umsetzung zu beachten?
Redaktionen, Designteams und Entwicklung sollten in enger Abstimmung sicherstellen, dass mediale Inhalte auf mehreren Sinneskanälen angeboten werden und technisch korrekt ausgezeichnet sind. Es geht nicht nur um gesetzliche Mindestanforderungen, sondern um echte Teilhabe. Wer Inhalte klar strukturiert, erklärt und in mehreren sensorischen Formen zugänglich macht, erreicht mehr Menschen und leistet einen Beitrag zu Inklusion und Nutzungsfreundlichkeit.
Im Folgenden werden die einzelnen Erfolgskriterien unter dem Prinzip Wahrnehmbarkeit praxisnah erläutert. Die Umsetzungsempfehlungen enthalten konkrete Hinweise für Redaktion, Entwicklung und Gestaltung. Dabei wird jedes Erfolgskriterium zunächst kurz erklärt. Im Anschluss folgen jeweils die Hinweise zur technischen Umsetzung. Die Erfolgskriterien sind in drei Konformitätsstufen eingeteilt:
Stufe A sind grundlegende Anforderungen, um Webauftritte und Webanwendungen nutzen zu können
Stufe AA ist der Standard, der für gute Zugänglichkeit erreicht werden sollte
Stufe AAA umfasst sehr hohe Anforderungen
Da öffentliche Stellen laut BITV 2.0 sowie Unternehmen nach dem BFSG zur Erfüllung der Stufen A und AA verpflichtet sind, konzentriert sich dieser Leitfaden auf genau diese. Die Stufe AAA kann zur Umsetzung des höchstmöglichen Maßes der Barrierefreiheit genutzt werden, bleibt an dieser Stelle jedoch außen vor. Sie kann jederzeit bei Bedarf ergänzend berücksichtigt werden.
Zur besseren Verständlichkeit findet ihr am Ende dieses Dokuments ein Glossar mit kurzen Erklärungen zentraler Begriffe rund um die folgenden Erklärungen.
Erfolgskriterien des Prinzips Wahrnehmbarkeit
1.1 Textalternativen
1.1.11 Nicht-Text-Inhalte (Stufe A):
Stellt für alle informative Nicht-Text-Inhalte (z. B. Bilder, Grafiken) Textalternativen bereit. Dies ermöglicht es Nutzenden mit Sehbeeinträchtigungen und kognitiven Beeinträchtigungen die Inhalte zu erfassen.
Umsetzungsempfehlung: Verwendet in HTML das alt-Attribut für informative Bilder. Für komplexe Grafiken wie Diagramme oder Infografiken nutzt zusätzlich eine ausführliche Beschreibung im Text oder verlinkt auf eine externe Beschreibung. Verwendet bei dekorativen Bildern leere Alt-Texte (alt=""), damit sie von Screenreadern ignoriert werden. Achtet bei Icons mit Funktion (z. B. Drucken, Suchen) auf eine sinnvolle Kennzeichnung, sofern keine sichtbare Beschriftung vorhanden ist. Sonst sollten diese als dekorativ gekennzeichnet werden.
1.2 Zeitbasierte Medien
1.2.1 Nur-Audio und Nur-Video (vorab aufgezeichnet) (Stufe A):
Bietet für vorab aufgezeichnete Audio- und stumme Videoinhalte entsprechende Alternativen in Textform an.
Umsetzungsempfehlung: Erstellt für Podcasts oder Interviews ohne visuelle Komponente ein vollständiges Transkript. Bei stummen Videos beschreibt in Textform, was im Bild zu sehen ist. Die Textbeschreibung kann entweder direkt auf der Seite stehen oder über einen Link erreichbar sein.
1.2.2 Untertitel (vorab aufgezeichnet) (Stufe A):
Stellt Untertitel für vorab aufgezeichnete Videos mit Ton bereit.
Umsetzungsempfehlung: Nutzt Untertitelungssoftware oder -dienste, um genaue Untertitel zu erstellen. Untertitel sollten gesprochene Inhalte, Sprecherwechsel und relevante Hintergrundgeräusche enthalten. Nutzt standardisierte Untertitelformate wie .srt. Achtet darauf, dass die Untertitel nicht fest ins Video eingebrannt sind, damit Nutzende sie ein- oder ausschalten können. Stellt eine hohe sprachliche Qualität und Lesbarkeit sicher, z. B. durch gut getimte Zeilenumbrüche, korrekte Rechtschreibung und ausreichend lange Einblendzeiten.
1.2.3 Audiodeskription oder Medienalternative (vorab aufgezeichnet) (Stufe A):
Bietet eine Möglichkeit an, visuelle Informationen auch hörbar oder als Text verfügbar zu machen.
Umsetzungsempfehlung: Erstellt zusätzlich zur Originalspur eine Version mit eingesprochener Beschreibung visueller Elemente (Audiodeskription). Die Audiodeskription wird dabei ausschließlich in den Sprechpausen eingefügt und muss daher in der Regel sehr kompakt formuliert sein. Sie ist nur dann erforderlich, wenn wesentliche Informationen über das Bild vermittelt werden, die nicht im Ton enthalten sind. Alternativ kann eine ausführliche Inhaltsbeschreibung als HTML verlinkt werden. Wichtig ist, dass Nutzende erkennen, dass es diese Alternative gibt. Es geht hierbei explizit um die Beschreibung visueller Inhalte in Videos, nicht um die Vorlesung von Textinhalten.
1.2.4 Untertitel (live) (Stufe AA):
Stellt für Live-Videoinhalte Untertitel bereit.
Umsetzungsempfehlung: Arbeitet mit Live-Untertitelungsdiensten oder Software, die Echtzeit-Transkription. Informiert die Teilnehmenden im Vorfeld, ob Untertitel bereitgestellt werden und wie diese aktiviert werden können. Stellt eine hohe sprachliche Qualität und Lesbarkeit sicher, z. B. durch gut getimte Zeilenumbrüche, korrekte Rechtschreibung und ausreichend lange Einblendzeiten.
Vorab aufgezeichnete Videos mit visuellen Informationen sollten eine Audiodeskription enthalten, um auch für sehbeeinträchtigte Nutzende verständlich zu sein.
Umsetzungsempfehlung: Sprecht Bildinhalte zwischen Dialogpausen oder in separater Version ein. Falls technisch aufwendig, bietet alternativ ein detailliertes Transkript mit Bildbeschreibung zum Download oder direkt auf der Seite an. Für Videos mit hohem narrativem oder atmosphärischem Anteil reicht ein Transkript in der Regel nicht aus, da es die audiovisuelle Wirkung und komplexe Bildsprache nicht adäquat überträgt. Geeignete Einsatzszenarien für Transkripte mit Bildbeschreibungen sind zum Beispiel: Lehrvideos mit klarer Struktur, Produkt- oder Erklärvideos, Webinare oder aufgezeichnete Fachvorträge mit Präsentationen, kurze Informationsclips ohne dramatische Bildwirkung sowie stille Videos oder Animationen ohne Ton, bei denen Transkripte die Inhalte vollständig erfassbar machen.
1.3 Anpassbar
1.3.1 Informationen und Beziehungen (Stufe A):
Stellt sicher, dass Informationen und Beziehungen, die durch visuelle oder auditive Mittel vermittelt werden, auch programmatisch von assistiven Technologien abgerufen werden können oder in Textform verfügbar sind.
Umsetzungsempfehlung: Nutzt semantisch korrektes HTML: h1 bis h6 für Überschriften, ul/ol für Listen, table für Tabellen mit Beschriftung. Vermeidet visuelle Formatierung mit leeren Zeilen oder reinem Text-Layout. Prüft die Struktur regelmäßig mit Screenreader-Test oder HTML-Validator.
1.3.2 Bedeutungsvolle Reihenfolge (Stufe A):
Inhalte sollten in einer sinnvollen und logischen Reihenfolge präsentiert werden, sodass sie bei allen Darstellungsformen verständlich und bedienbar bleiben.
Umsetzungsempfehlung: Achtet bei der Strukturierung von HTML-Inhalten auf die visuelle wie auch die programmatische Reihenfolge. Nutzt semantische Container und überprüft die Lesereihenfolge mithilfe von Screenreadern oder browserbasierten Testwerkzeugen. Inhaltliche Zusammenhänge wie Beschriftung und Eingabefeld oder Bild und Beschreibung sollten im Quelltext direkt aufeinander folgen.
1.3.3 Sensorische Merkmale (Stufe A):
Anweisungen sollten nicht ausschließlich auf sensorische Hinweise wie Farbe, Form, Größe oder Position verweisen.
Umsetzungsempfehlung: Ergänzt Farbangaben durch textliche Hinweise. Beispiel: Statt „Klicken Sie auf den grünen Knopf“ sollte es heißen „Klicken Sie auf den grünen Knopf mit dem Pfeilsymbol rechts unten“. Achtet darauf, dass der Hinweis auch per Screenreader verständlich ist, indem z. B. aria-labels verwendet werden.
1.3.4 Ausrichtung (Stufe AA):
Inhalte sollten sowohl im Hoch- als auch im Querformat nutzbar sein, ohne dass eine bestimmte Bildschirmorientierung erforderlich ist.
Umsetzungsempfehlung: Stellt sicher, dass die Seite sich dynamisch an die jeweilige Ausrichtung anpasst. Verwendet flexible Layouts, die sich im CSS anpassen lassen. Vermeidet JavaScript-Sperren, die bestimmte Orientierungen erzwingen. Testet eure Anwendungen auf Mobilgeräten in beiden Formaten.
1.3.5 Eingabezweck identifizieren (Stufe AA):
Der Zweck von Eingabefeldern sollte so gekennzeichnet sein, dass Browser und assistive Technologien ihn erkennen und automatische Eingabehilfen (z. B. Autofill) unterstützen können. Ein Eingabefeld z. B. für „Nachname“ muss auch als Nachnamefeld erkennbar sein.
Umsetzungsempfehlung: Verwendet standardisierte HTML-Attribute wie autocomplete="name", email, postal-code etc., damit mobile Betriebssysteme oder Passwortmanager die Felder korrekt vorausfüllen können. Prüft die Wirksamkeit mit einem Autofill-Test auf unterschiedlichen Geräten.
1.4 Unterscheidbar
1.4.1 Verwendung von Farbe (Stufe A):
Informationen dürfen nicht ausschließlich durch Farbe vermittelt werden, da dies für Menschen mit Farbsehschwächen problematisch ist.
Umsetzungsempfehlung: Ergänzt farbliche Kennzeichnungen immer durch Text oder Symbole. Beispielsweise sollte ein Fehlerfeld nicht nur rot umrandet sein, sondern auch mit einem Hinweis wie „Fehler: Bitte ausfüllen“ versehen sein.
1.4.2 Audiosteuerung (Stufe A):
Audioinhalte sollten nicht automatisch starten und länger als drei Sekunden dauern, da automatisch abgespielte Klänge die Nutzung für viele Menschen mit Beeinträchtigungen erschweren können.
Umsetzungsempfehlung: Vermeidet Autoplay bei Toninhalten. Wenn unvermeidlich, stellt gut sichtbare Bedienelemente zur Verfügung, mit denen Nutzende die Wiedergabe pausieren oder stoppen können.
1.4.3 Kontrast (Minimum) (Stufe AA):
Texte sollten ausreichend vom Hintergrund abgehoben sein, damit sie auch bei eingeschränktem Sehvermögen lesbar sind.
Umsetzungsempfehlung: Nutzt Kontrastverhältnisse von mindestens 4,5:1 bei normalem Text und 3:1 bei großem Text. Verwendet Tools wie den WebAIM Contrast Checker zur Prüfung.
1.4.4 Textgröße ändern (Stufe AA):
Texte sollten bis auf 200 % vergrößerbar sein, ohne dass Inhalte abgeschnitten oder unleserlich werden.
Umsetzungsempfehlung: Nutzt relative Maßeinheiten wie „em“ oder „rem“. Vermeidet feste Layoutbreiten oder absolute Schriftgrößen in Pixeln.
1.4.5 Bilder von Text (Stufe AA):
Wenn Text in Bildern (Schriftgrafiken) enthalten ist, kann er nicht ohne Qualitätsverlust (Schärfe) vergrößert oder von Hilfsmitteln wie einem Screenreader vorgelesen werden. Dadurch haben manche Menschen Schwierigkeiten, die Informationen zu erkennen oder zu verstehen.
Umsetzungsempfehlung: Nutzt HTML-Text statt Text in Grafiken. Wenn ein Bildtext unverzichtbar ist (z. B. in Logos), stellt eine gleichwertige Textalternative bereit.
1.4.10 Umfluss (Reflow) (Stufe AA):
Digitale Inhalte müssen auch bei starker Vergrößerung übersichtlich, verständlich und ohne horizontales Scrollen nutzbar sein.
Umsetzungsempfehlung: Stellt sicher, dass eure Webinhalte bei einem Zoom von bis zu 400 % bei einer Fensterbreite von 1280 px weiterhin ohne horizontales Scrollen lesbar bleiben (ausgenommen sind Inhalte, bei denen horizontales Scrollen aus funktionalen Gründen notwendig ist, z. B. bei Tabellen oder interaktiven Diagrammen). Nutzt responsive Layouts, die sich flexibel an verschiedene Bildschirmgrößen anpassen.
1.4.11 Nicht-Text-Kontrast (Stufe AA):
Grafische Inhalte und interaktive Elemente müssen ebenfalls gut erkennbar sein.
Umsetzungsempfehlung: Stellt sicher, dass Icons, Formfelder und Steuerelemente ein Kontrastverhältnis von mindestens 3:1 zum Hintergrund haben.
1.4.12 Textabstand (Stufe AA):
Nutzende sollten Textzeilen mit ausreichendem Abstand lesen können.
Umsetzungsempfehlung: Richtet die Darstellung so aus, dass beifolgenden Werten keine Inhalte überlappen oder verloren gehen: z.B. Zeilenhöhe 1,5-fach, Absatzabstand mindestens 1,5-mal der Textgröße, Buchstabenabstand 0,12em, Wortabstand 0,16em.
1.4.13 Inhalt bei Hover oder Fokus (Stufe AA):
Zusätzliche Inhalte wie Tooltips sollten bei Bedarf durch Eingabegeräte angezeigt und leicht geschlossen werden können.
Umsetzungsempfehlung: Achtet darauf, dass eingeblendete Inhalte nicht automatisch verschwinden, solange Nutzende mit dem Mauszeiger oder der Tastatur interagieren. Bietet klare Schaltflächen zum Schließen an (z. B. ein „X“ oder die Esc-Taste).
Beschreibung: Prüft u. a. Textgrößen, Kontrast und Struktur auf einer Seite.
Diese Liste erhebt nicht den Anspruch vollständig zu sein, es gibt noch viele andere Tools und Werkzeuge. Dies ist lediglich ein Einstieg.
Glossar
.em und .rem: Relative Maßeinheiten in CSS zur Schriftgrößen- und Abstandsdefinition. Sie passen sich an die eingestellte Textgröße an und ermöglichen eine flexible Skalierung.
.srt: Ein Untertitelformat (SubRip Subtitle), das Zeitstempel und Textzeilen enthält. Wird häufig für Videountertitel genutzt.
Alternativtexte (alt-text): Texte, die als Alternativen für Bilder hinterlegt werden. Sie werden z. B. von Screenreadern vorgelesen und ermöglichen so Menschen mit Sehbeeinträchtigung den Zugang zu Bildinhalten.
ARIA-Label: Ein Attribut zur barrierefreien Beschriftung von Elementen, insbesondere von Icons oder Schaltflächen, die keinen sichtbaren Text enthalten.
Assistive Technologien: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe, die Menschen mit Beeinträchtigungen die Nutzung digitaler Inhalte ermöglichen.
Autocomplete: HTML-Attribut, mit denen Browser Formularfelder automatisch ausfüllen können. Sie verbessern Komfort und Barrierefreiheit.
Autofill: Funktion von Webbrowsern, die Formularfelder automatisch mit gespeicherten Daten befüllt.
Autoplay: Automatischer Start von Medieninhalten wie Videos oder Audio beim Seitenaufruf.
BFSG: Barrierefreiheitsstärkungsgesetz. Regelt die Barrierefreiheit für bestimmte Produkte und Dienstleistungen in der Privatwirtschaft.
BITV: Barrierefreie-Informationstechnik-Verordnung. Regelt die digitale Barrierefreiheit für öffentliche Stellen auf Bundesebene in Deutschland.
CSS: Cascading Style Sheets. Sprache zur Gestaltung von HTML-Inhalten, z. B. für Farben, Abstände, Schriftgrößen und Layout.
Formfelder: Eingabeelemente in Formularen wie Textfelder, Checkboxen oder Auswahlmenüs. Sie müssen beschriftet und per Tastatur bedienbar sein.
H1–H6: HTML-Überschriftenelemente. Sie bilden eine hierarchische Struktur und erleichtern die Navigation mit Hilfstechnologien.
HTML: Hypertext Markup Language. Strukturierungssprache für Webseiten, z. B. zur Auszeichnung von Überschriften, Absätzen und Formularen.
Javascript: Skriptsprache zur Umsetzung dynamischer Inhalte und Interaktionen auf Webseiten. Muss barrierefrei integriert und steuerbar sein.
normaler Text und großer Text: Als normaler Text gilt Text in Standardgröße, also in der Regel unter 18 Punkt oder unter 14 Punkt fett. Als großer Text gilt Text mit mindestens 18 Punkt (ca. 24 Pixel) oder 14 Punkt fett (ca. 18,66 Pixel).
Quelltext: Der programmierte Code einer Webseite, z. B. HTML, CSS oder Javascript.
Responsive Design: Ein Layout-Prinzip, bei dem sich Webseiten an verschiedene Bildschirmgrößen anpassen.
Schriftgrafiken: Text, der als Bild eingebunden ist.
Steuerelemente: Interaktive Bedienelemente wie Schaltflächen, Links oder Eingabefelder.
Table: HTML-Element zur Darstellung von tabellarischen Daten.
Transkript: Textliche Aufbereitung von Audio- oder Videoinhalten.
Ul/OI: HTML-Elemente für ungeordnete (
) und geordnete () Listen.
WCAG: Die Web Content Accessibility Guidelines sind internationale Richtlinien zur digitalen Barrierefreiheit.
Dieser Text kann auch als PDF Datei heruntergeladen werden.
Bedienbarkeit: Inhalte zugänglich und steuerbar machen
Das WCAG-Prinzip Bedienbarkeit stellt sicher, dass alle Funktionen einer digitalen Oberfläche von allen Nutzenden bedient werden können, unabhängig von ihren individuellen Fähigkeiten oder bevorzugten Eingabemethoden. Im Fokus stehen insbesondere Menschen, die keine Maus verwenden, Screenreader nutzen oder mit motorischen Einschränkungen arbeiten. Bedienbarkeit betrifft nicht nur technische Interaktionen, sondern auch die sinnvolle Strukturierung von Navigation, Formularen und Fokusführung.
Warum ist Bedienbarkeit so wichtig?
Ohne durchdachte Bedienung können selbst die besten Inhalte unerreichbar bleiben. Wenn interaktive Elemente nicht per Tastatur erreichbar sind oder der Fokus nicht sichtbar ist, können Menschen mit Beeinträchtigungen digitale Angebote nicht nutzen.
Was ist bei der Umsetzung zu beachten?
Die barrierefreie Bedienung eines Webauftrittes oder einer mobilen Anwendung ist ein Zusammenspiel aus sauberem HTML, semantischer Struktur, sinnvoller Fokusführung und Einhaltung technischer Standards. Redaktion, Entwicklung und UX sollten gemeinsam dafür sorgen, dass Nutzerinteraktionen ohne Hürden möglich sind, mit Tastatur, Bildschirmvergrößerung oder anderen assistiven Technologien.
Zur besseren Verständlichkeit findet ihr am Ende dieses Dokuments ein Glossar mit kurzen Erklärungen zentraler Begriffe rund um die folgenden Erklärungen.
Im Folgenden werden die einzelnen Erfolgskriterien unter dem Prinzip Bedienbarkeit praxisnah erläutert. Die Umsetzungsempfehlungen enthalten konkrete Hinweise für Redaktion, Entwicklung und Gestaltung. Dabei wird jedes Erfolgskriterium zunächst kurz erklärt. Im Anschluss folgen jeweils die Hinweise zur technischen Umsetzung. Die Erfolgskriterien sind in drei Konformitätsstufen eingeteilt:
Stufe A sind grundlegende Anforderungen, um Webauftritte und Webanwendungen nutzen zu können.
Stufe AA ist der Standard, der für gute Zugänglichkeit erreicht werden sollte.
Stufe AAA umfasst sehr hohe Anforderungen.
Da öffentliche Stellen laut BITV 2.0 sowie Unternehmen nach dem BFSG zur Erfüllung der Stufen A und AA verpflichtet sind, konzentriert sich dieser Leitfaden auf genau diese. Die Stufe AAA kann zur Umsetzung des höchstmöglichen Maßes der Barrierefreiheit genutzt werden, bleibt an dieser Stelle jedoch außen vor. Sie kann jederzeit bei Bedarf ergänzend berücksichtigt werden.
Erfolgskriterien des Prinzips Bedienbarkeit
2.1 Tastaturzugänglichkeit
2.1.1. Tastatur (Stufe A):
Alle interaktive Bedienelemente eines Webauftritt müssen vollständig über die Tastatur bedienbar sein. Das bedeutet, dass Menschen, die keine Maus nutzen können, alle Elemente bedienen und steuern können.
Umsetzungsempfehlung: Nutzt standardisierte HTML-Elemente wie
2.1.2 Keine Tastaturfalle (Stufe A):
Nutzende dürfen bei der Tastaturbedienung nicht in einem Element (z. B. einem Popup-Fenster oder interaktiven Widget) „feststecken“. Sie müssen jederzeit zu anderen Inhalten navigieren können.
Umsetzungsempfehlung: Sorgt dafür, dass Fokusbereiche klar definiert sind und Nutzende jederzeit weiter navigieren oder zurückkehren können. Tastaturfallen werden vermieden, in dem man z. B. den Fokus von einem Element wieder entfernen kann, in dem eine Interaktion abgebrochen werden kann.
2.1.4 Zeichentastenbefehle (Stufe A):
Tastenkürzel, die nur aus einem einzelnen Zeichen bestehen, können versehentlich ausgelöst werden und sollten deshalb vermieden werden, deaktivierbar oder anpassbar sein.
Umsetzungsempfehlung: Vermeidet Einzeltasten-Shortcuts ohne Modifikatortasten (wie Strg oder Alt). Falls ihr solche Shortcuts verwendet, bietet Möglichkeiten an, diese anzupassen oder abzuschalten. Beispiel: Ein Mailprogramm nutzt „e“ zum Archivieren von E-Mails. Dies sollte entweder auf eine Kombination (z. B. Alt+E) geändert oder durch Nutzende abschaltbar sein.
2.2 Ausreichende Zeit
2.2.1. Zeiteinteilung anpassbar (Stufe A):
Bei zeitlich begrenzten Inhalten müssen Nutzende die Möglichkeit haben, die Zeitbegrenzung zu verlängern, zu deaktivieren oder Eingaben zu speichern. Zeitlich begrenzte Inhalte sind beispielsweise Online-Formulare, Buchungsprozesse (wie bei Zugtickets, Hotelreservierungen oder Konzertkarten), Online-Tests und -Prüfungen oder automatisierte Abmeldeprozesse bei Inaktivität (z. B. Online-Banking).
Umsetzungsempfehlung: Implementiert vor Ablauf einer Sitzung eine deutliche Vorwarnung, bevor ein Zeitlimit erreicht ist. Gleichzeitig muss Nutzenden eine klare Möglichkeit gegeben werden, dieses Limit zu verlängern, zu pausieren oder ganz abzuschalten. Ebenfalls sollte sichergestellt sein, dass Nutzereingaben nicht verloren gehen, falls die Zeit doch einmal abläuft, etwa durch automatische Speicherung von Daten oder Zwischenspeichern nach Abschnitten.
2.2.2. Anhalten, Beenden, Ausblenden (Stufe A):
Automatisch ablaufende Inhalte, wie Animationen oder Karussells, dürfen nicht von anderen Inhalten ablenken und müssen pausier bar oder zu stoppen sein. Diese Steuerungsmöglichkeiten sollten immer eingebaut werden, sobald Inhalte automatisch starten, sich bewegen, sich regelmäßig aktualisieren oder rotieren, und Nutzende diese Inhalte nicht selbst aktiv gestartet haben. Dies gilt insbesondere für Inhalte, die länger als fünf Sekunden laufen, sich wiederholen oder fortlaufend aktualisieren.
Umsetzungsempfehlung: Bietet gut sichtbare Schaltflächen oder Steuerungen an, um automatisch rotierende oder abspielende Inhalte zu stoppen oder auszublenden, besser noch werden Animationen nicht automatisch gestartet. Achtet darauf, dass die Bedienelemente per Tastatur zugänglich sind.
2.3 Anfälle und körperliche Reaktionen
2.3.1. Drei Blitze oder Unterschwellenwert (Stufe A):
Vermeidet Inhalte, die häufiger als dreimal pro Sekunde blinken oder blitzen, da diese bei Personen epileptische Anfälle auslösen können.
Umsetzungsempfehlung: Verzichtet vollständig auf stark blinkende oder blitzende Animationen. Wenn Bewegungseffekte unvermeidbar sind, prüft ihre Frequenz sorgfältig, sodass sie deutlich unter drei Blitzen pro Sekunde bleibt.
2.4 Navigierbar
2.4.1. Blöcke umgehen (Stufe A):
Wiederholte Inhalte (z. B. Navigation, Header) sollten übersprungen werden können, um direkt zum gewünschten Inhalt zu gelangen. In der Praxis hat sich bewährt, drei „Skip-Links“ einzubauen. Diese müssen am Anfang der Seite stehen, um Nutzenden eine schnelle und unkomplizierte Navigation zu ermöglichen. So müssen Nutzende, die auf Tastaturbedienung oder Screenreader angewiesen sind, nicht bei jedem Seitenaufruf durch Menüs, Kopfbereiche oder Banner navigieren.
Umsetzungsempfehlung: Setzt am Anfang jeder Seite drei fokussierbare „Zum Inhalt springen“-Links ein, die beim Tabulatorfokus sichtbar werden und direkt zum Hauptinhalt führen.
2.4.2. Seiten-Titel (Stufe A):
Jede Seite benötigt einen eindeutigen, aussagekräftigen Titel, der ihren Inhalt klar beschreibt. Ein guter Seitentitel setzt sich aus der individuellen Seite und dem Namen des gesamten Webauftrittes zusammen. Ein klar formulierter Seitentitel ist besonders wichtig, weil er die erste Orientierungshilfe für viele Nutzende darstellt, insbesondere für Personen, die Screenreader verwenden oder mehrere Browser-Tabs gleichzeitig geöffnet haben. Der Titel erscheint in der Titelleiste des Browsers, in der Tab-Darstellung und in der Verlaufsliste. Ein gut gewählter Titel hilft, sich schneller zu orientieren, Inhalte zu unterscheiden und gezielt zwischen Seiten zu wechseln. Er trägt maßgeblich zur Zugänglichkeit und zur besseren Nutzbarkeit bei, da unklare oder gleichlautende Titel wie „Startseite“ oder „Home“ keinen Hinweis auf den spezifischen Inhalt oder Zweck der Seite geben.
Umsetzungsempfehlung: Verwendet das HTML-Element
, um für jede Seite einen spezifischen, beschreibenden Titel zu vergeben, der Kontext schafft (z. B. „Kontakt – Stadtverwaltung Musterstadt“).</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-243-fokus-reihenfolge-stufe-a">2.4.3. Fokus-Reihenfolge (Stufe A):</h6>
<p>Die Reihenfolge der Tastaturnavigation muss logisch und nachvollziehbar sein. Sie sollte programmatisch korrekt umgesetzt sein, das heißt: Die Anordnung der Bedienelemente im HTML-Quellcode sollte der visuellen und inhaltlichen Struktur entsprechen. Dadurch wird sichergestellt, dass Nutzende, die ausschließlich mit der Tastatur navigieren – zum Beispiel durch die Tabulatortaste – die Inhalte in der erwarteten Reihenfolge durchlaufen können. Eine logisch aufgebaute Fokusreihenfolge ermöglicht eine barrierefreie Nutzung ohne Verwirrung oder Umwege.</p>
<p><strong>Umsetzungsempfehlung</strong>: Strukturiert eure HTML-Elemente im Quellcode in derselben logischen Reihenfolge, wie sie visuell dargestellt werden. Vermeidet manuelle Eingriffe in die Tab-Reihenfolge (kein übermäßiger Einsatz von tabindex).</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-244-linkzweck-im-kontext-stufe-a">2.4.4. Linkzweck (im Kontext) (Stufe A):</h6>
<p>Der Zweck jedes Links muss aus dem Kontext klar hervorgehen. Das bedeutet: Nutzende müssen schon beim Lesen des Linktexts erkennen können, wohin der Link führt und was sie dort erwartet. Dies ist besonders wichtig für Menschen, die Screenreader nutzen, denn diese können sich eine Liste aller Links auf einer Seite ausgeben lassen – dabei wird der Linktext oft aus dem Zusammenhang gerissen</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt klare und beschreibende Linktexte (z. B. „Weitere Informationen zur Anmeldung“ statt nur „hier klicken“). Alternativ stellt sicher, dass der Kontext unmittelbar klarstellt, wohin der Link führt.</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-245-mehrere-wege-stufe-aa">2.4.5. Mehrere Wege (Stufe AA):</h6>
<p>Inhalte sollten über mindestens zwei Wege (z. B. Navigation, Suche oder Sitemap) erreichbar sein. Besonders für Menschen mit kognitiven Beeinträchtigungen, Lernschwierigkeiten oder Sehbeeinträchtigungen kann es hilfreich sein, Inhalte auf unterschiedlichen Wegen ansteuern zu können. Auch für Screenreader-Nutzende oder Personen, die sich schnell einen Überblick verschaffen möchten, ist eine alternative Navigation hilfreich.</p>
<p><strong>Umsetzungsempfehlung</strong>: Ergänzt die Navigation durch eine leicht auffindbare Suchfunktion oder eine Sitemap, damit Nutzende mehrere Möglichkeiten haben, Inhalte zu finden.</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-246-überschriften-und-beschriftungen-stufe-aa">2.4.6. Überschriften und Beschriftungen (Stufe AA):</h6>
<p>Überschriften und Beschriftungen müssen klar und eindeutig den Inhalt oder Zweck des jeweiligen Abschnitts oder Elements beschreiben.</p>
<p><strong>Umsetzungsempfehlung</strong>: Verwendet den Zweck beschreibende Beschriftungen bei Formularen. So verbessert ihr die Orientierung der Nutzenden und Verständlichkeit der Inhalte.</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-247-sichtbarer-fokus-stufe-aa">2.4.7. Sichtbarer Fokus (Stufe AA):</h6>
<p>Der aktuell fokussierte Bereich muss deutlich sichtbar sein, um Nutzenden, die eine Tastatur benutzen, Orientierung zu bieten.</p>
<p><strong>Umsetzungsempfehlung</strong>: Gestaltet Fokuszustände per CSS deutlich sichtbar (z. B. eine auffällige Umrandung oder Hintergrundfarbe). Entfernt niemals den Standard-Fokus (outline) ohne sichtbare Alternative.</p>
<h5 id="wcag-prinzip-2-bedienbarkeit-25-eingabemodalitäten">2.5 Eingabemodalitäten</h5>
<h6 id="wcag-prinzip-2-bedienbarkeit-251-zeigergesten-stufe-a">2.5.1. Zeigergesten (Stufe A):</h6>
<p>Verzichtet auf komplexe Gesten, die mehrere Finger oder komplizierte Bewegungen erfordern. Solche Gesten sind für viele Nutzende schwer auszuführen – zum Beispiel für Personen mit motorischen Beeinträchtigungen, Zittern, geringer Feinmotorik oder eingeschränkter Handbeweglichkeit. Auch bei der Nutzung von unterstützender Technik wie Bildschirmvergrößerungen oder alternativen Eingabemethoden (z. B. Spracheingabe, Einhandbedienung) sind komplexe Gesten oft nicht praktikabel. Wenn wichtige Funktionen ausschließlich über Gesten wie „Zweifingerwischen“, „Dreifachtippen“ oder „Langdruck mit Wisch“ ausgelöst werden, kann dies für bestimmte Gruppen bedeuten, dass sie diese Inhalte nicht oder nur sehr schwer nutzen können.</p>
<p><strong>Umsetzungsempfehlung</strong>: Stellt sicher, dass alle Funktionen auch durch einfache Gesten (Klick, einfacher Tap) ausführbar sind. Wenn ihr komplexe Gesten verwendet, bietet alternative Eingabemöglichkeiten an (z. B. zusätzliche Schaltflächen).</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-252-zeigeraufhebung-stufe-a">2.5.2. Zeigeraufhebung (Stufe A):</h6>
<p>Aktionen, die durch Zeigerbewegungen ausgelöst werden, müssen einfach abzubrechen oder rückgängig zu machen sein. Besonders für Personen mit motorischen Einschränkungen, eingeschränkter Kontrolle über die Eingabe oder bei der Nutzung von Augen- oder Sprachsteuerung ist dies ein zentrales Nutzungshindernis. Ohne die Möglichkeit, eine Aktion abzubrechen oder rückgängig zu machen, führt ein einzelner Fehler möglicherweise zum Verlust von Eingaben, zu ungewollten Änderungen oder zu Frustration.</p>
<p><strong>Umsetzungsempfehlung</strong>: Gestaltet Drag-and-Drop-Aktionen so, dass sie durch einfaches Loslassen außerhalb des Zielbereichs abgebrochen werden können. Bietet Nutzenden die Möglichkeit, versehentliche Aktionen leicht rückgängig zu machen.</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-253-beschriftung-im-namen-stufe-a">2.5.3. Beschriftung im Namen (Stufe A):</h6>
<p>Die sichtbare Beschriftung eines interaktiven Elements sollte mit dem maschinenlesbaren Namen (z. B. aria-label) übereinstimmen. Das ist wichtig für Spracherkennungstechnologien.</p>
<p><strong>Umsetzungsempfehlung</strong>: Stellt sicher, dass sichtbarer Text und der programmatisch ermittelbare Name identisch sind. Ein Button mit der sichtbaren Beschriftung „Anfrage absenden“ darf nicht nur mit „Absenden“ oder einem anderen verkürzten Text programmiert sein.</p>
<h6 id="wcag-prinzip-2-bedienbarkeit-254-bewegungsauslösung-stufe-a">2.5.4. Bewegungsauslösung (Stufe A):</h6>
<p>Funktionen, die durch Bewegungen wie Schütteln oder Neigen ausgelöst werden, müssen auch anderweitig bedienbar sein. Denn nicht alle Nutzenden sind in der Lage, solche Bewegungen mit einem Gerät auszuführen – etwa aufgrund motorischer Beeinträchtigungen, eingeschränkter Beweglichkeit, Koordinationsschwierigkeiten oder weil sie Hilfsmittel wie Rollstühle oder Halterungen verwenden, in denen Geräte fest fixiert sind. Auch technische Einschränkungen wie deaktivierte Bewegungssensoren oder die Nutzung auf stationären Geräten (z. B. Desktop-PCs) können solche Gesten unmöglich machen. Wenn eine Funktion ausschließlich über Bewegung gesteuert wird, ist sie für viele Menschen nicht zugänglich. Daher muss es immer eine gleichwertige Alternative geben.</p>
<p><strong>Umsetzungsempfehlung</strong>: Bietet eine alternative Methode zur Auslösung dieser Funktionen an, z. B. durch zusätzliche sichtbare Schaltflächen oder Menüpunkte. Beispiel: „Zum Anfang scrollen durch Schütteln“ erhält zusätzlich eine fest platzierte Schaltfläche „Nach oben“.</p>
<h3 id="wcag-prinzip-2-bedienbarkeit-weiterführende-informationen-aus-der-bfit">Weiterführende Informationen aus der BFIT:</h3>
<ul>
<li><p><a href="/bfit-leitfaeden/5.0/redaktion/strukturierung-von-textinhalten.html#" data-pdf-page="strukturierung-von-textinhalten" data-pdf-anchor="" data-pdf-level="2">Strukturierung von Textinhalten</a></p></li>
<li><p><a href="/bfit-leitfaeden/5.0/technik/skip-links-fuer-barrierefreie-webseiten.html#" data-pdf-page="skip-links-für-barrierefreie-webseiten" data-pdf-anchor="" data-pdf-level="2">Skip Links für barrierefreie Webseiten</a></p></li>
<li><p><a href="#" data-pdf-page="" data-pdf-anchor="" data-pdf-level="2"></a></p></li>
</ul>
<h3 id="wcag-prinzip-2-bedienbarkeit-tools-zur-prüfung-der-bedienbarkeit">Tools zur Prüfung der Bedienbarkeit</h3>
<h4 id="wcag-prinzip-2-bedienbarkeit-1-tastaturbedienung">1. Tastaturbedienung</h4>
<p>Nutzt die <strong>Tab-Taste,</strong> um zu prüfen:</p>
<ul>
<li><p>Ist jedes interaktive Element erreichbar?</p></li>
<li><p>Wird der Fokus klar sichtbar angezeigt?</p></li>
<li><p>Ist die Fokusreihenfolge logisch?</p></li>
<li><p>Gibt es keine „Tastaturfalle“ (Elemente, in denen man hängen bleibt)?</p></li>
</ul>
<h4 id="wcag-prinzip-2-bedienbarkeit-2-fokusreihenfolge-und-tastaturnavigation">2. Fokusreihenfolge und Tastaturnavigation</h4>
<h5 id="wcag-prinzip-2-bedienbarkeit-fokus-reihenfolge-anzeigen">Fokus-Reihenfolge anzeigen</h5>
<ul>
<li><p>Beschreibung: Visualisiert die aktuelle Tab-Reihenfolge der Seite, um die logische Navigationsabfolge zu überprüfen</p></li>
<li><p>Link: <a href="https://bitvtest.de/bookmarklets/focus-order.html">https://bitvtest.de/bookmarklets/focus-order.html</a></p></li>
</ul>
<h5 id="wcag-prinzip-2-bedienbarkeit-tabindex-prüfen">Tabindex prüfen</h5>
<ul>
<li><p>Beschreibung: Zeigt alle Elemente mit tabindex an und warnt bei ungünstigen oder fehlerhaften Werten.</p></li>
<li><p>Link: <a href="https://bitvtest.de/bookmarklets/tabindex.html">https://bitvtest.de/bookmarklets/tabindex.html</a></p></li>
</ul>
<p>Diese Liste erhebt nicht den Anspruch vollständig zu sein, es gibt noch viele andere Tools und Werkzeuge. Dies ist lediglich ein Einstieg.</p>
<h3 id="wcag-prinzip-2-bedienbarkeit-glossar">Glossar:</h3>
<ul>
<li><p><strong><a href></strong>: HTML-Element zur Erstellung von Links.</p></li>
<li><p><strong><button></strong>: Ein HTML-Element für Schaltflächen.</p></li>
<li><p><strong><input></strong>: HTML-Element zur Eingabe von Daten, z. B. in Formularen. Es kann verschiedene Typen wie Text, E-Mail oder Checkbox enthalten.</p></li>
<li><p><strong><title></strong>: Das HTML-Element, das den Seitentitel im Browser-Tab und in der Verlaufsliste festlegt.</p></li>
<li><p><strong>aria-label</strong>: Ein Attribut zur barrierefreien Beschriftung von Elementen, insbesondere von Icons oder Schaltflächen, die keinen sichtbaren Text enthalten.</p></li>
<li><p><strong>Assistive Technologien</strong>: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe, die Menschen mit Beeinträchtigungen die Nutzung digitaler Inhalte ermöglichen.</p></li>
<li><p><strong>BFSG</strong>: Barrierefreiheitsstärkungsgesetz. Regelt die Barrierefreiheit für bestimmte Produkte und Dienstleistungen in der Privatwirtschaft.</p></li>
<li><p><strong>BITV</strong>: Barrierefreie-Informationstechnik-Verordnung. Regelt die digitale Barrierefreiheit für öffentliche Stellen auf Bundesebene in Deutschland.</p></li>
<li><p><strong>Cookie</strong>: Kleine Datenspeicher auf Websites, die Nutzungsverhalten speichern.</p></li>
<li><p><strong>CSS</strong>: Cascading Style Sheets. Sprache zur Gestaltung von HTML-Inhalten, z. B. für Farben, Abstände, Schriftgrößen und Layout.</p></li>
<li><p><strong>Fokusführung</strong>: Bezeichnet die gezielte Steuerung der Tastaturnavigation durch interaktive Elemente.</p></li>
<li><p><strong>Fokusindikatoren</strong>: Visuelle Hervorhebungen, die anzeigen, welches Element gerade per Tastatur fokussiert ist (z. B. Rahmen oder Farbänderungen).</p></li>
<li><p><strong>Formfelder</strong>: Eingabeelemente in Formularen wie Textfelder, Checkboxen oder Auswahlmenüs.</p></li>
<li><p><strong>H1–H6</strong>: HTML-Überschriftenelemente.</p></li>
<li><p><strong>Header</strong>: Der obere Bereich einer Webseite, der meist Navigation, Logo und Suchfunktion enthält.</p></li>
<li><p><strong>HTML</strong>: Hypertext Markup Language. Strukturierungssprache für Webseiten, z. B. zur Auszeichnung von Überschriften, Absätzen und Formularen.</p></li>
<li><p><strong>interaktive Elemente</strong>: Bedienbare Inhalte wie Links, Buttons, Formulare oder Widgets, mit denen Nutzende aktiv interagieren können.</p></li>
<li><p><strong>Karussells</strong>: Automatisch rotierende Inhaltselemente (z. B. Bilderslider).</p></li>
<li><p><strong>Modifikatortasten</strong>: Tastenkombinationen, bei denen zusätzliche Tasten wie Strg, Alt oder Shift gedrückt werden.</p></li>
<li><p><strong>Outline</strong>: CSS-Eigenschaft, die Fokuszustände visuell sichtbar macht.</p></li>
<li><p><strong>Popup-Fenster</strong>*:* Temporäre Fenster, die sich über der Webseite öffnen.</p></li>
<li><p><strong>Quelltext</strong>: Der programmierte Code einer Webseite, z. B. HTML, CSS oder JavaScript.</p></li>
<li><p><strong>Reihenfolge</strong>: Bezieht sich auf die logische und visuelle Abfolge von Elementen, z. B. in Formularen oder beim Tab-Fokus.</p></li>
<li><p><strong>Sitemap</strong>: Strukturübersicht aller Seiten einer Website, oft alphabetisch oder thematisch gegliedert.</p></li>
<li><p><strong>Skip Links</strong>: Versteckte Links am Seitenanfang, mit denen Tastaturnutzende direkt zum Hauptinhalt oder zu wichtigen Bereichen springen können.</p></li>
<li><p><strong>Spracherkennungstechnologien</strong>: Technologien, mit denen Webseiten per Sprache gesteuert werden.</p></li>
<li><p><strong>Tabindex</strong>: HTML-Attribut zur Steuerung der Tabulatorreihenfolge.</p></li>
<li><p><strong>Tab-Taste</strong>: Tastaturtaste zur Navigation zwischen fokussierbaren Elementen auf einer Website.</p></li>
<li><p><strong>UX (User Experience)</strong>: Erlebnis und Wahrnehmung eines digitalen Angebots durch die Nutzenden.</p></li>
<li><p><strong>WCAG</strong>: Die Web Content Accessibility Guidelines sind internationale Richtlinien zur digitalen Barrierefreiheit.</p></li>
<li><p><strong>Widget</strong>: Kleine interaktive Module auf Webseiten (z. B. Wetteranzeige, Terminkalender), die häufig zusätzlichen Funktionen bieten.</p></li>
</ul>
<h2 id="wcag-prinzip-3-verständlichkeit">WCAG: Prinzip 3 Verständlichkeit</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/grundlagen/wcag-prinzip3.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/wcag-verstaendlichkeit.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../wcag-was-ist-neu-version2_2/image2.png" style="" alt="" />
<h3 id="wcag-prinzip-3-verständlichkeit-verständlichkeit-inhalte-verständlich-und-nachvollziehbar-gestalten">Verständlichkeit: Inhalte verständlich und nachvollziehbar gestalten</h3>
<p>Das WCAG-Prinzip <strong>Verständlichkeit</strong> stellt sicher, dass digitale Inhalte und Interaktionen für alle Menschen nachvollziehbar und eindeutig und sind. Es betrifft sprachliche Formulierungen, die Struktur von Benutzeroberflächen sowie das Verhalten von Webseiten bei der Eingabe oder Navigation. Verständlichkeit ist besonders wichtig für Menschen mit kognitiven Beeinträchtigungen, Lernschwierigkeiten oder geringen Sprachkenntnissen, aber auch für alle, die sich schnell orientieren oder komplexe Inhalte erfassen wollen.</p>
<h3 id="wcag-prinzip-3-verständlichkeit-warum-ist-verständlichkeit-so-wichtig">Warum ist Verständlichkeit so wichtig?</h3>
<p>Selbst wenn Inhalte technisch erreichbar und visuell gut gestaltet sind, können sie unzugänglich bleiben, wenn Sprache, Struktur oder Interaktionen verwirren. Wenn zum Beispiel die Hauptsprache der Seite nicht korrekt angegeben ist oder Formulare unklar beschriftet sind, entstehen Barrieren, die die Nutzung erschweren oder unmöglich machen.</p>
<h3 id="wcag-prinzip-3-verständlichkeit-was-ist-bei-der-umsetzung-zu-beachten">Was ist bei der Umsetzung zu beachten?</h3>
<p>Verständliche digitale Angebote erfordern die Zusammenarbeit von Redaktion, UX-Design und Entwicklung. Wichtig sind unter anderem klar formulierte Inhalte, einheitliche Benennungen für gleiche Funktionen, gut strukturierte Formulare sowie vorhersehbares Verhalten bei der Bedienung.</p>
<p>Im Folgenden werden die Erfolgskriterien des Prinzips Robustheit praxisnah erläutert. Die Umsetzungsempfehlungen enthalten konkrete Hinweise für Redaktion, Entwicklung und Gestaltung. Dabei wird jedes Erfolgskriterium zunächst kurz erklärt. Im Anschluss folgen jeweils Hinweise zur technischen Umsetzung.</p>
<p>Die Erfolgskriterien sind in drei Stufen unterteilt:</p>
<ul>
<li><p>Stufe A umfasst grundlegende Anforderungen, die nötig sind, damit Webauftritte und Anwendungen überhaupt zugänglich sind.</p></li>
<li><p>Stufe AA ist der empfohlene Standard für gute digitale Zugänglichkeit.</p></li>
<li><p>Stufe AAA enthält zusätzliche Anforderungen für ein sehr hohes Maß an Barrierefreiheit.</p></li>
</ul>
<p>Da öffentliche Stellen gemäß BITV 2.0 und Unternehmen gemäß BFSG zur Umsetzung der Stufen A und AA verpflichtet sind, konzentriert sich dieser Leitfaden ausschließlich auf diese beiden Konformitätsstufen. Die Kriterien der Stufe AAA können ergänzend berücksichtigt werden, wenn ein besonders hoher Barrierefreiheitsstandard erreicht werden soll.</p>
<p>Zur besseren Verständlichkeit findet ihr am Ende dieses Dokuments ein Glossar mit kurzen Erklärungen zentraler Begriffe rund um die folgenden Erklärungen.</p>
<h4 id="wcag-prinzip-3-verständlichkeit-erfolgskriterien-des-prinzips-verständlichkeit">Erfolgskriterien des Prinzips Verständlichkeit</h4>
<h5 id="wcag-prinzip-3-verständlichkeit-31-lesbar">3.1 Lesbar</h5>
<h6 id="wcag-prinzip-3-verständlichkeit-311-sprache-der-seite-stufe-a">3.1.1 Sprache der Seite (Stufe A):</h6>
<p>Die Hauptsprache des Inhalts muss im HTML-Dokument korrekt angegeben sein. Die Angabe der Hauptsprache ist essenziell für die Zugänglichkeit von Inhalten für Nutzende mit assistiven Technologien, insbesondere für Personen, die Screenreader verwenden. Screenreader wie JAWS, NVDA oder VoiceOver verwenden die Sprachangabe, um die richtige Aussprache, Intonation und Betonung zu wählen. Ist keine oder eine falsche Sprache hinterlegt, kann der Text unverständlich oder irreführend wiedergegeben werden.</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt das lang-Attribut im <html>-Element (z. B. <html lang="de"> für Deutsch). Diese Angabe gilt seitenweit und sollte einheitlich und konsistent verwendet werden. So können Screenreader oder andere assistive Technologien den Text korrekt ausgeben. Ohne diese Information wird die Sprache falsch erkannt oder falsch ausgesprochen.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-312-sprache-von-teilen-stufe-aa">3.1.2 Sprache von Teilen (Stufe AA):</h6>
<p>Wenn Abschnitte oder einzelne Wörter in einer anderen Sprache, als der angegebenen Hauptsprache verfasst sind, müssen diese ausgezeichnet sein. Viele Webseiten enthalten einzelne Wörter, Fachbegriffe oder Abschnitte in anderen Sprachen, z. B. englische Zitate, französische Begriffe oder mehrsprachige Informationen. Ohne eine korrekte Sprachauszeichnung erkennen Screenreader und andere assistive Technologien diese Abschnitte nicht als fremdsprachig. Das führt zu falscher Aussprache, erschwerter Verständlichkeit und kann den Lesefluss erheblich stören.</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt auch innerhalb des Inhalts das lang-Attribut, etwa <span lang="en">Accessibility</span>. Das ermöglicht Screenreadern eine korrekte Aussprache und signalisiert den Wechsel deutlich. Bei längeren Textabschnitten kann das Attribut auch auf größere Strukturelemente angewendet werden. Diese Anforderung betrifft nicht Begriffe, die bereits erläuternd im Duden stehen (z. B. „E-Mail“, „Computer“). Verwendet nicht zu viele Sprachauszeichnungen innerhalb eines Textes – zu häufige Sprachwechsel führen dazu, dass Screenreader ständig die Stimme wechseln, was die Verständlichkeit stark erschwert.</p>
<h5 id="wcag-prinzip-3-verständlichkeit-32-vorhersehbar">3.2 Vorhersehbar</h5>
<h6 id="wcag-prinzip-3-verständlichkeit-hinweis-zu-allen-erfolgskriterien-unter-32">Hinweis zu allen Erfolgskriterien unter 3.2:</h6>
<p>Alle Veränderungen der Benutzeroberfläche, sei es durch Fokus, Eingabe, Navigation oder Interaktion mit Komponenten dürfen nur dann automatisch erfolgen, wenn Nutzende vorher eindeutig darüber informiert wurden. Ohne eine solche Vorwarnung gilt jede automatisch ausgelöste Kontextänderung als unvorhersehbar und stellt eine erhebliche Barriere dar.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-321-bei-fokus-stufe-a">3.2.1 Bei Fokus (Stufe A):</h6>
<p>Das Setzen des Fokus (z. B. durch Tastaturnavigation via Tab-Taste) darf keine unerwarteten Aktionen auslösen. Wenn sich bei der Tastaturnavigation plötzlich etwas verändert, nur weil ein Element den Fokus erhält, zum Beispiel ein Menü aufgeht oder die Seite neu lädt, kann das für viele Nutzende sehr verwirrend sein. Besonders für Menschen mit kognitiven Einschränkungen oder motorischen Beeinträchtigungen kann das zur Desorientierung führen oder sogar dazu, dass sie die Seite nicht mehr bedienen können.</p>
<p><strong>Umsetzungsempfehlung</strong>: Vermeidet automatische Weiterleitungen oder das plötzliche Öffnen von Fenstern, nur weil ein Element den Fokus erhält. Nutzende sollen Aktionen bewusst auslösen können (z. B. durch Enter, Klick oder Auswahländerung). Verwendet die JavaScript-Events, onchange oder onclick, aber nicht onfocus als Auslöser für Seitenwechsel oder Inhaltsänderungen.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-322-bei-eingabe-stufe-a">3.2.2 Bei Eingabe (Stufe A):</h6>
<p>Veränderungen an Eingaben (z. B. Auswahl in Dropdowns) dürfen nicht automatisch zu Seitenwechseln oder Kontextänderungen führen, außer die Änderung wird angekündigt oder ist zu erwarten. Viele Nutzende sind auf die Tastaturnavigation angewiesen, darunter auch Personen, die mit Screenreadern oder anderen assistiven Technologien arbeiten. Wenn sich durch eine einfache Eingabe unvorhergesehen der Seiteninhalt verändert, kann dies zu Orientierungsverlust oder Fehlbedienung führen. Besonders Menschen mit kognitiven Beeinträchtigungen oder motorischen Einschränkungen profitieren davon, wenn sie selbst bestimmen können, wann eine Änderung ausgelöst wird.</p>
<p><strong>Umsetzungsempfehlung</strong>: Startet Funktionen erst, wenn eine Eingabe aktiv bestätigt wird, z. B. mit einer „Weiter“- oder „Absenden“-Schaltfläche. Wenn automatische Änderungen technisch notwendig sind, muss dies vorher deutlich gemacht werden (z. B. durch einen erklärenden Text, ein ARIA-Hinweis oder einen sichtbaren Hinweis im Formular).</p>
<h6 id="wcag-prinzip-3-verständlichkeit-323-konsistente-navigation-stufe-aa">3.2.3 Konsistente Navigation (Stufe AA):</h6>
<p>Navigationsmechanismen, die auf mehreren Seiten innerhalb eines Webauftritt wiederkehren, sollen in derselben Reihenfolge und mit denselben Bezeichnungen erscheinen. Viele Nutzende, besonders Menschen mit kognitiven Einschränkungen, blinde Personen oder Menschen mit motorischen Einschränkungen, sind auf verlässliche Strukturen angewiesen. Wenn Navigationselemente zwischen Seiten wechseln, umbenannt werden oder an unerwarteten Stellen erscheinen, führt das zu Verwirrung und Orientierungslosigkeit.</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt identische Navigationsstrukturen auf allen Seiten, z. B. durch Templates. Achtet auf einheitliche Bezeichnungen und testet, ob Menüstrukturen auch bei Seitenwechsel stabil bleiben.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-324-konsistente-bezeichnung-stufe-aa">3.2.4 Konsistente Bezeichnung (Stufe AA):</h6>
<p>Wenn Komponenten mit derselben Funktion mehrfach innerhalb eines Webauftritt vorkommen, sollen sie einheitlich benannt sein. Für viele Nutzende, etwa blinde Menschen mit Screenreader, Personen mit kognitiven Einschränkungen oder Lernschwierigkeiten ist die Wiedererkennbarkeit von Funktionen entscheidend für die selbstbestimmte Nutzung einer Website. Uneinheitliche Bezeichnungen können zu Verwirrung führen und wichtige Funktionen unzugänglich machen.</p>
<p><strong>Umsetzungsempfehlung</strong>: Verwendet durchgängig dieselben Begriffe für dieselbe Funktion, sowohl im sichtbaren Text als auch in programmatischen Labels. Legt redaktionelle Standards fest: z. B. einheitliche Begriffe für „Suche“, „Kontakt“, „Weiter“, „Abbrechen“ Bei Verwendung von Symbolen oder Icons: einheitliche ARIA-Labels oder Alt-Texte verwenden.</p>
<h5 id="wcag-prinzip-3-verständlichkeit-33-eingabehilfe">3.3 Eingabehilfe</h5>
<h6 id="wcag-prinzip-3-verständlichkeit-331-fehleridentifikation-stufe-a">3.3.1 Fehleridentifikation (Stufe A):</h6>
<p>Wenn ein Eingabefehler erkannt wird, muss dieser beschrieben werden, also was falsch ist und (wenn möglich), wo der Fehler liegt. Viele Menschen, insbesondere mit kognitiven Einschränkungen oder Nutzende von assistiven Technologien, sind auf klare Rückmeldungen angewiesen. Eine bloße Markierung wie „Fehler“ ohne Beschreibung hilft nicht weiter. Nutzende müssen verstehen, was genau falsch war, um ihre Eingabe erfolgreich zu korrigieren.</p>
<p><strong>Umsetzungsempfehlung</strong>: Hebt fehlerhafte Felder hervor (z. B. mit einem roten Rahmen) und bietet eine konkrete Textmeldung wie „Bitte geben Sie Ihre E-Mail-Adresse im Format <a href="mailto:name@domain.de">name@domain.de</a> ein“. Achtet darauf, dass das Eingabefeld und die Fehlermeldung programmatisch verbunden sind. Fehler sollten nicht ausschließlich durch Farbe angezeigt werden. Zusätzliche textuelle Hinweise sind erforderlich, um sicherzustellen, dass alle Nutzenden die Fehlermeldung wahrnehmen können.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-332-beschriftungen-oder-anleitungen-stufe-a">3.3.2 Beschriftungen oder Anleitungen (Stufe A):</h6>
<p>Jedes Eingabefeld soll eine klare Beschriftung oder Anleitung haben, um korrekt ausgefüllt werden zu können. Unbeschriftete oder unverständliche Felder sind eine Barriere. Ohne aussagekräftige Beschriftung kann nicht erkannt werden, welche Informationen verlangt werden.</p>
<p><strong>Umsetzungsempfehlung</strong>: Verwendet für alle Formularfelder sprechende Beschriftungen (z. B. „Telefonnummer (optional)“) und bei Bedarf kurze Hinweise darunter. Platzhaltertexte (Placeholders) allein sind keine ausreichenden Beschriftungen, da sie beim Eintippen verschwinden und dadurch insbesondere für Nutzenden mit kognitiven Einschränkungen oder Screenreader nicht mehr zugänglich sind.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-333-vorschläge-zur-fehlerkorrektur-stufe-aa">3.3.3 Vorschläge zur Fehlerkorrektur (Stufe AA):</h6>
<p>Bei automatisch erkannten Eingabefehlern sollen den Nutzenden Korrekturvorschläge angeboten werden. Dies soll insbesondere Menschen mit kognitiven Beeinträchtigungen oder Sehbehinderungen helfen, Fehler zu verstehen und zu korrigieren. Viele Nutzende sind auf klare Anleitungen angewiesen, um Eingabefehler zu beheben. Ohne spezifische Hinweise können sie den Fehler nicht identifizieren oder wissen nicht, wie sie ihn korrigieren sollen. Dies kann dazu führen, dass das Ausfüllen von Formularen abgebrochen wird oder die Formulare falsch ausgefüllt werden.</p>
<p><strong>Umsetzungsempfehlung</strong>: Statt allgemeiner Hinweise wie „Ungültige Eingabe“ sollten spezifische Anleitungen gegeben werden, z. B. „Bitte geben Sie eine fünfstellige Postleitzahl ein“. Fehlermeldungen sollten in unmittelbarer Nähe zum betroffenen Eingabefeld angezeigt werden und programmatisch mit diesem verknüpft sein, z. B. durch aria-describedby. Bei komplexen Eingaben kann die Angabe eines Beispiels hilfreich sein, z. B. „Geben Sie Ihre Telefonnummer im Format 030 1234567 ein“.</p>
<h6 id="wcag-prinzip-3-verständlichkeit-334-fehlervermeidung-bei-sensiblen-prozessen-stufe-aa">3.3.4 Fehlervermeidung bei sensiblen Prozessen (Stufe AA):</h6>
<p>Bei Eingaben, die rechtliche oder finanzielle Folgen haben, soll es Mechanismen geben, um Fehler zu vermeiden oder zu korrigieren. Ein versehentliches Versenden von falschen oder unvollständigen Daten kann ernste Folgen haben, gerade im Kontakt mit Behörden. Nutzende sollen die Möglichkeit haben, ihre Angaben zu prüfen und bei Bedarf zu ändern.</p>
<p><strong>Umsetzungsempfehlung</strong>: Stellt eine Zusammenfassung bereit, bevor das Formular abgeschickt wird („Bitte prüfen Sie Ihre Angaben“). Das hilft besonders bei langen Formularen oder juristisch relevanten Vorgängen. Ermöglicht Nutzenden, ihre Angaben einfach zu korrigieren, z. B. über „Zurück“-Buttons oder editierbare Vorschauansichten. Überprüft Eingaben schon während der Eingabe (z. B. Formatprüfung bei E-Mail, IBAN).</p>
<h3 id="wcag-prinzip-3-verständlichkeit-weiterführende-informationen-aus-der-bfit">Weiterführende Informationen aus der BFIT:</h3>
<ul>
<li><p><a href="/bfit-leitfaeden/5.0/redaktion/sprachauszeichnung.html#" data-pdf-page="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte" data-pdf-anchor="" data-pdf-level="2">Sprachauszeichnung: Die richtige Sprache für barrierefreie Inhalte!</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/">Barrierefreie Gestaltung von User Interface-Elementen</a></p></li>
</ul>
<h3 id="wcag-prinzip-3-verständlichkeit-tools-zur-prüfung-der-verständlichkeit--robustheit">Tools zur Prüfung der Verständlichkeit & Robustheit</h3>
<h4 id="wcag-prinzip-3-verständlichkeit-1-sprache-der-seite-und-von-abschnitten">1. Sprache der Seite und von Abschnitten</h4>
<h5 id="wcag-prinzip-3-verständlichkeit-bookmarklet-lang">Bookmarklet „Lang“</h5>
<ul>
<li><p>Beschreibung: Prüft, ob die Hauptsprache der Seite korrekt mit dem lang-Attribut ausgezeichnet ist. Hilft dabei, anderssprachige Wörter oder Abschnitte zu identifizieren, die ebenfalls mit lang ausgezeichnet sein sollten. <strong>Link</strong>:</p></li>
<li><p>Link: <a href="https://bitvtest.de/bookmarklets/lang.html">https://bitvtest.de/bookmarklets/lang.html</a></p></li>
</ul>
<h4 id="wcag-prinzip-3-verständlichkeit-2-aussagekräftige-überschriften-und-beschriftungen">2. Aussagekräftige Überschriften und Beschriftungen:</h4>
<h5 id="wcag-prinzip-3-verständlichkeit-bookmarklet-inhalte-gegliedert">Bookmarklet „Inhalte gegliedert“</h5>
<ul>
<li><p>Beschreibung: Hilft dabei, die Klarheit und Aussagekraft von Überschriften zu bewerten, indem es die semantische Struktur der Seite anzeigt.</p></li>
<li><p>Link: <a href="https://bitvtest.de/bookmarklets/structure.html">https://bitvtest.de/bookmarklets/structure.html</a></p></li>
</ul>
<h4 id="wcag-prinzip-3-verständlichkeit-3-fehlermeldungen-und-eingabehilfen">3. Fehlermeldungen und Eingabehilfen</h4>
<h5 id="wcag-prinzip-3-verständlichkeit-wave-evaluation-tool">WAVE Evaluation Tool</h5>
<ul>
<li><p>Beschreibung: Analysiert Formulare auf korrekte Beschriftungen, Fehlermeldungen und Eingabehilfen.</p></li>
<li><p>Link: <a href="https://wave.webaim.org/">https://wave.webaim.org/</a></p></li>
</ul>
<p>Diese Liste erhebt nicht den Anspruch vollständig zu sein, es gibt noch viele andere Tools und Werkzeuge. Dies ist lediglich ein Einstieg.</p>
<h3 id="wcag-prinzip-3-verständlichkeit-glossar">Glossar:</h3>
<ul>
<li><p><strong>Alt-Texte</strong>: Alternative Textbeschreibungen für Bilder.</p></li>
<li><p><strong>ARIA-Label</strong>: Ein Attribut zur barrierefreien Beschriftung von Elementen, insbesondere von Icons oder Schaltflächen, die keinen sichtbaren Text enthalten.</p></li>
<li><p><strong>Assistive Technologien</strong>: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe.</p></li>
<li><p><strong>BFSG</strong>: Barrierefreiheitsstärkungsgesetz.</p></li>
<li><p><strong>BITV</strong>: Barrierefreie-Informationstechnik-Verordnung.</p></li>
<li><p><strong>Dropdowns</strong>: Auswahlelemente, bei denen eine Liste von Optionen eingeblendet wird, z. B. in einem <select>-Feld.</p></li>
<li><p><strong>Formfelder</strong>: Eingabeelemente in Formularen wie Textfelder oder Checkboxen.</p></li>
<li><p><strong>H1–H6</strong>: HTML-Überschriftenelemente.</p></li>
<li><p><strong>HTML</strong>: Hypertext Markup Language. Strukturierungssprache für Webseiten, z. B. zur Auszeichnung von Überschriften, Absätzen und Formularen.</p></li>
<li><p><strong>JavaScript</strong>: Skriptsprache zur Umsetzung dynamischer Inhalte und Interaktionen auf Webseiten. Muss barrierefrei integriert und steuerbar sein.</p></li>
<li><p><strong>JAWS</strong>: Ein weit verbreiteter Screenreader für Windows, der Webseiteninhalte für blinde und sehbehinderte Menschen vorliest oder auf einer Braillezeile ausgibt.</p></li>
<li><p><strong>NVDA</strong>: Ein kostenloser Screenreader für Windows, der Inhalte vorliest und mit verschiedenen Hilfstechnologien zusammenarbeitet.</p></li>
<li><p><strong>Onchange</strong>: Ein JavaScript-Ereignis, das ausgelöst wird, wenn sich der Wert eines Elements ändert (z. B. Auswahl in einem Dropdown-Menü).</p></li>
<li><p><strong>Onclick</strong>: Ein JavaScript-Ereignis, das bei einem Mausklick oder Tastendruck (z. B. Enter auf Schaltflächen) ausgelöst wird.</p></li>
<li><p><strong>Onfocus</strong>: Ein JavaScript-Ereignis, das ausgelöst wird, wenn ein Element den Fokus erhält.</p></li>
<li><p><strong>Programmatisch</strong>: Der Begriff bezieht sich auf Informationen im Quellcode, die maschinell ausgelesen werden können, z. B. von Screenreadern.</p></li>
<li><p><strong>Quellcode</strong>: Der programmierte Code einer Webseite, z. B. HTML.</p></li>
<li><p><strong>UX-Design</strong>: Kurz für „User Experience Design“. Gestaltungsansatz, der auf gute Benutzerführung, Verständlichkeit und barrierefreie Bedienbarkeit abzielt.</p></li>
<li><p><strong>VoiceOver</strong>: Der integrierte Screenreader auf Apple-Geräten (z. B. iPhone, iPad, Mac), der Inhalte vorliest und per Gesten oder Tastatur steuerbar ist.</p></li>
<li><p><strong>WCAG</strong>: Die Web Content Accessibility Guidelines sind internationale Richtlinien zur digitalen Barrierefreiheit.</p></li>
</ul>
<h2 id="wcag-prinzip-4-robustheit">WCAG: Prinzip 4 Robustheit</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/grundlagen/wcag-prinzip4.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/wcag-robustheit.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../wcag-was-ist-neu-version2_2/image2.png" style="" alt="" />
<h3 id="wcag-prinzip-4-robustheit-robustheit-inhalte-technologisch-zuverlässig-und-zukunftssicher-gestalten">Robustheit: Inhalte technologisch zuverlässig und zukunftssicher gestalten</h3>
<p>Das WCAG-Prinzip <strong>Robustheit</strong> stellt sicher, dass digitale Inhalte von möglichst vielen Geräten, Browsern und assistiven Technologien zuverlässig verarbeitet werden können. Ziel ist es, Inhalte so technisch sauber und standardkonform aufzubauen, dass sie auch bei Weiterentwicklung von Technologien zugänglich bleiben.</p>
<h3 id="wcag-prinzip-4-robustheit-warum-ist-robustheit-so-wichtig">Warum ist Robustheit so wichtig?</h3>
<p>Technische Fehler in HTML-Strukturen oder falsche Angaben zu Rollen, Zuständen oder Namen von Elementen führen dazu, dass Hilfsmittel wie Screenreader Informationen nicht korrekt interpretieren können. Auch moderne Browser oder zukünftige Assistenzsysteme könnten Inhalte dann nicht mehr zuverlässig darstellen.</p>
<h3 id="wcag-prinzip-4-robustheit-was-ist-bei-der-umsetzung-zu-beachten">Was ist bei der Umsetzung zu beachten?</h3>
<p>Robuste Inhalte setzen voraus, dass der Quellcode fehlerfrei und standardkonform ist. Dazu gehört z. B., dass HTML-Elemente korrekt verschachtelt und geschlossen sind und Rollen und Zustände bei interaktiven Elementen eindeutig ausgezeichnet sind. Auch ARIA-Attribute müssen korrekt verwendet werden.</p>
<p>Im Folgenden werden die Erfolgskriterien des Prinzips <strong>Robustheit</strong> praxisnah erläutert. Die Umsetzungsempfehlungen enthalten konkrete Hinweise für Redaktion, Entwicklung und Gestaltung. Dabei wird jedes Erfolgskriterium zunächst kurz erklärt. Im Anschluss folgen jeweils Hinweise zur technischen Umsetzung.</p>
<p>Die Erfolgskriterien sind in drei Stufen unterteilt:</p>
<ul>
<li><p>Stufe A umfasst grundlegende Anforderungen, die nötig sind, damit Webauftritte und Anwendungen überhaupt zugänglich sind.</p></li>
<li><p>Stufe AA ist der empfohlene Standard für gute digitale Zugänglichkeit.</p></li>
<li><p>Stufe AAA enthält zusätzliche Anforderungen für ein sehr hohes Maß an Barrierefreiheit.</p></li>
</ul>
<p>Da öffentliche Stellen gemäß BITV 2.0 und Unternehmen gemäß BFSG zur Umsetzung der Stufen A und AA verpflichtet sind, konzentriert sich dieser Leitfaden ausschließlich auf diese beiden Konformitätsstufen. Die Kriterien der Stufe AAA können ergänzend berücksichtigt werden, wenn ein besonders hoher Barrierefreiheitsstandard erreicht werden soll.</p>
<p>Zur besseren Verständlichkeit findet ihr am Ende dieses Dokuments ein Glossar mit kurzen Erklärungen zentraler Begriffe rund um die folgenden Erklärungen.</p>
<h4 id="wcag-prinzip-4-robustheit-erfolgskriterien-des-prinzips-robustheit">Erfolgskriterien des Prinzips Robustheit</h4>
<h5 id="wcag-prinzip-4-robustheit-41-kompatibel">4.1 Kompatibel</h5>
<h6 id="wcag-prinzip-4-robustheit-411-parsing-stufe-a">4.1.1 Parsing (Stufe A):</h6>
<p>Der Code einer Webseite sollte fehlerfrei sein und korrekt geparst werden können. Fehlerhafter HTML-Code kann dazu führen, dass Screenreader oder andere assistive Technologien Inhalte nicht oder falsch interpretieren. Jede ID auf einer Webseite darf nur einmal vergeben werden. Wird dieselbe ID mehrfach verwendet, kann das dazu führen, dass Bildschirmleseprogramme, Tastatursteuerungen oder andere Hilfsmittel nicht mehr eindeutig erkennen, welches Element gemeint ist.</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt HTML-Validatoren wie den W3C Markup Validation Service. Bezieht auch ARIA-Rollen und -Attribute in die Prüfung mit ein. Verwendet valide HTML-Syntax gemäß dem verwendeten Doctype.</p>
<h6 id="wcag-prinzip-4-robustheit-412-name-rolle-wert-stufe-a">4.1.2 Name, Rolle, Wert (Stufe A):</h6>
<p>Alle benutzbaren Komponenten (z. B. Formulare, Links, Schaltflächen, Widgets) müssen programmatisch korrekt identifizierbar sein: mit Name, Rolle und aktuellem Status- oder Wertangabe. Screenreader und andere Hilfsmittel müssen erkennen, was ein Element ist (z. B. ein Button), wie es heißt („Suche starten“) und was sein aktueller Zustand ist (z. B. aktiviert/deaktiviert, ausgewählt, geöffnet). Ohne diese Informationen können Nutzende das Element nicht richtig bedienen oder einordnen.</p>
<p><strong>Umsetzungsempfehlung</strong>: Nutzt ARIA-Rollen und -Attribute gezielt und korrekt: z. B. role="button", aria-expanded="true". Beschriftet Bedienelemente mit sichtbarem und programmatischem Namen (label, aria-label, aria-labelledby). Stellt sicher, dass der Zustand dynamischer Komponenten aktualisiert wird (aria-checked, aria-selected usw.)</p>
<h6 id="wcag-prinzip-4-robustheit-413-statusmeldungen-stufe-aa">4.1.3 Statusmeldungen (Stufe AA):</h6>
<p>Statusmeldungen, die sich ohne Benutzerinteraktion ändern (z. B. Erfolgs- oder Fehlermeldungen), müssen von assistiven Technologien automatisch erkannt und übermittelt werden. Nutzende, die mit Screenreadern arbeiten, bekommen visuelle Änderungen oft nicht mit, z. B. wenn nach Absenden eines Formulars ein Hinweis erscheint: „Ihre Nachricht wurde gesendet.“ Ohne programmatische Erkennbarkeit ist die Information für sie nicht zugänglich.</p>
<p><strong>Umsetzungsempfehlung</strong>: Verwendet ARIA-Live-Regionen für dynamische Statusupdates und platziert Live-Regionen semantisch sinnvoll.</p>
<h3 id="wcag-prinzip-4-robustheit-weiterführende-informationen-aus-der-bfit">Weiterführende Informationen aus der BFIT:</h3>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/">Barrierefreie Gestaltung von User Interface-Elementen</a></p></li>
</ul>
<h3 id="wcag-prinzip-4-robustheit-tools-zur-prüfung-der-robustheit">Tools zur Prüfung der Robustheit</h3>
<h4 id="wcag-prinzip-4-robustheit-1--html--und-code-validierung">1. HTML- und Code-Validierung</h4>
<h5 id="wcag-prinzip-4-robustheit-w3c-validator">W3C Validator</h5>
<ul>
<li><p>Beschreibung: prüft, ob der HTML- oder XHTML-Code valide und standardkonform ist.</p></li>
<li><p>Link: <a href="https://validator.w3.org">https://validator.w3.org</a></p></li>
</ul>
<h5 id="wcag-prinzip-4-robustheit-nu-html-checker-alternative-w3c-prüfung-auch-per-datei-upload">Nu HTML Checker; Alternative W3C-Prüfung (auch per Datei-Upload)</h5>
<ul>
<li><p>Beschreibung: erkennt strukturelle und semantische Fehler:</p></li>
<li><p>Link: <a href="https://validator.w3.org/nu">https://validator.w3.org/nu</a></p></li>
</ul>
<h4 id="wcag-prinzip-4-robustheit-aria-rollen-und-zustände-überprüfen">ARIA-Rollen und Zustände überprüfen</h4>
<h5 id="wcag-prinzip-4-robustheit-tollwerk-bookmarklet-aria-struktur-anzeigen">Tollwerk Bookmarklet: „ARIA-Struktur anzeigen“</h5>
<ul>
<li><p>Beschreibung: Visualisiert ARIA-Rollen und Landmarken.</p></li>
<li><p>Link: <a href="https://bitvtest.de/bookmarklets/landmarks.html">https://bitvtest.de/bookmarklets/landmarks.html</a></p></li>
</ul>
<h6 id="wcag-prinzip-4-robustheit-wave-evaluation-tool">WAVE Evaluation Tool</h6>
<ul>
<li><p>Beschreibung: Das Tool unterstützt die Prüfung robuster technischer Umsetzung, indem es aufzeigt, wo der Code problematisch für die maschinelle Interpretation ist.</p></li>
<li><p>Link: <a href="https://wave.webaim.org/">https://wave.webaim.org/</a></p></li>
</ul>
<p>Diese Liste erhebt nicht den Anspruch vollständig zu sein, es gibt noch viele andere Tools und Werkzeuge. Dies ist lediglich ein Einstieg.</p>
<h3 id="wcag-prinzip-4-robustheit-glossar">Glossar:</h3>
<ul>
<li><p><strong>ARIA-Label</strong>: Ein Attribut zur barrierefreien Beschriftung von Elementen, insbesondere von Icons oder Schaltflächen, die keinen sichtbaren Text enthalten.</p></li>
<li><p><strong>Assistive Technologien</strong>: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe, die Menschen mit Beeinträchtigungen die Nutzung digitaler Inhalte ermöglichen.</p></li>
<li><p><strong>BFSG</strong>: Barrierefreiheitsstärkungsgesetz.</p></li>
<li><p><strong>BITV</strong>: Barrierefreie-Informationstechnik-Verordnung.</p></li>
<li><p><strong>Browser</strong>: Programme zur Darstellung von Webseiten, z. B. Firefox, Chrome, Safari oder Edge.</p></li>
<li><p><strong>Doctype</strong>: Der Dokumenttyp (z. B. <!DOCTYPE html>) kennzeichnet den verwendeten HTML-Standard einer Webseite.</p></li>
<li><p><strong>geparst / Parsing</strong>: Das Einlesen und Interpretieren des Codes (z. B. HTML oder CSS) durch den Browser oder durch assistive Technologien.</p></li>
<li><p><strong>HTML</strong>: Hypertext Markup Language. Strukturierungssprache für Webseiten, z. B. zur Auszeichnung von Überschriften, Absätzen und Formularen.</p></li>
<li><p><strong>HTML-Syntax</strong>: Die formalen Regeln, nach denen HTML geschrieben wird.</p></li>
<li><p><strong>ID</strong>: Ein eindeutiger Bezeichner (Attribut id="...") innerhalb des HTML-Dokuments, mit dem einzelne Elemente gezielt angesprochen werden können.</p></li>
<li><p><strong>JavaScript</strong>: Skriptsprache zur Umsetzung dynamischer Inhalte und Interaktionen auf Webseiten. Muss barrierefrei integriert und steuerbar sein.</p></li>
<li><p><strong>Programmatisch</strong>: Der Begriff bezieht sich auf Informationen im Quellcode, die maschinell ausgelesen werden können, z. B. von Screenreadern.</p></li>
<li><p><strong>Rollen, Zuständen oder Namen von Elementen</strong>: Informationen, die assistive Technologien benötigen, um interaktive Elemente zu erkennen und zu beschreiben. Rollen (z. B. „Button“), Zustände (z. B. „aktiviert“, „deaktiviert“) und Namen (z. B. „Suchen“) können programmatisch über HTML oder ARIA vergeben werden.</p></li>
<li><p><strong>Standardkonform</strong>: Bedeutet, dass der Code den offiziellen Webstandards entspricht.</p></li>
<li><p><strong>UX-Design</strong>: Kurz für „User Experience Design“. Gestaltungsansatz, der auf gute Benutzerführung, Verständlichkeit und barrierefreie Bedienbarkeit abzielt.</p></li>
<li><p><strong>Validatoren</strong>: Werkzeuge zur Überprüfung des HTML- und CSS-Codes auf Einhaltung von Standards.</p></li>
<li><p><strong>WCAG</strong>: Die Web Content Accessibility Guidelines sind internationale Richtlinien zur digitalen Barrierefreiheit.</p></li>
</ul>
<h2 id="wcag-neue-anforderungen-der-wcag-22">WCAG: Neue Anforderungen der WCAG 2.2</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/grundlagen/wcag-was-ist-neu-version2_2.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_wcag_2_2.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../wcag-was-ist-neu-version2_2/image2.png" style="" alt="" />
<h3 id="wcag-neue-anforderungen-der-wcag-22-einführung-was-ist-neu-in-wcag-22">Einführung: Was ist neu in WCAG 2.2</h3>
<p>Mit der WCAG-Version 2.2 wurden insgesamt sechs neue A- und AA-Erfolgskriterien eingeführt und ein Erfolgskriterium gestrichen. So sollen gezielt Lücken in den bisherigen Richtlinien (WCAG 2.1) geschlossen werden. Diese neuen Anforderungen wurden entwickelt, um insbesondere die mobile Nutzung, die Zugänglichkeit für Menschen mit kognitiven Beeinträchtigungen und die allgemeine Benutzerfreundlichkeit weiter zu stärken.</p>
<p>Im Mittelpunkt steht eine konsequente Ausrichtung auf reale Nutzungssituationen:</p>
<ul>
<li><p>Wie navigieren Menschen mit assistiven Technologien durch ein Formular?</p></li>
<li><p>Wie erkennbar ist der Tastaturfokus auf einem Smartphone?</p></li>
<li><p>Und wie nachvollziehbar sind Login-Prozesse für Menschen mit eingeschränktem Kurzzeitgedächtnis?</p></li>
</ul>
<p>Die WCAG 2.2 erweitert diese Grundlagen um Anforderungen, die oft in der Praxis gefordert, aber bisher nicht ausdrücklich vorgeschrieben waren. Dazu gehören:</p>
<ul>
<li><p>Sichtbarkeit des Tastaturfokus (auch auf kleinen Bildschirmen)</p></li>
<li><p>Konsistente Platzierung von Hilfsangeboten</p></li>
<li><p>Barrierefreie Authentifizierungsprozesse</p></li>
</ul>
<p>Diese Erfolgskriterien unterstützen nicht nur Menschen mit kognitiven Einschränkungen, motorischen Beeinträchtigungen oder Sehbeeinträchtigungen, sondern verbessern die allgemeine Benutzerfreundlichkeit für alle.</p>
<p>Im Folgenden werden die neuen und geänderten Erfolgskriterien der WCAG 2.2 praxisnah erläutert. Die Umsetzungsempfehlungen enthalten konkrete Hinweise für Redaktion, Entwicklung und Gestaltung. Dabei wird jedes Erfolgskriterium zunächst kurz erklärt.</p>
<p>Im Anschluss folgen jeweils Hinweise zur technischen Umsetzung.</p>
<p>Die Erfolgskriterien sind in drei Stufen unterteilt:</p>
<ul>
<li><p>Stufe A umfasst grundlegende Anforderungen, die nötig sind, damit Webauftritte und Anwendungen überhaupt zugänglich sind.</p></li>
<li><p>Stufe AA ist der empfohlene Standard für gute digitale Zugänglichkeit</p></li>
<li><p>Stufe AAA enthält zusätzliche Anforderungen für ein sehr hohes Maß an Barrierefreiheit.</p></li>
</ul>
<p>Da öffentliche Stellen gemäß BITV 2.0 und Unternehmen gemäß BFSG zur Umsetzung der Stufen A und AA verpflichtet sind, konzentriert sich dieser Leitfaden ausschließlich auf diese beiden Konformitätsstufen. Die Erfolgskriterien der Stufe AAA können ergänzend berücksichtigt werden, wenn ein besonders hoher Barrierefreiheitsstandard erreicht werden soll.</p>
<p>Die für die digitale Barrierefreiheit in Deutschland maßgebliche Norm EN 301 549 (Version 3.2.1) verweist aktuell auf die Erfolgskriterien der WCAG 2.1 hin. Diese technische Grundlage gilt sowohl für den öffentlichen Sektor als auch, im Rahmen des BFSG.</p>
<p>Die Norm EN 301 549 wird derzeit überarbeitet. Mit der nächsten Version werden die Erfolgskriterien der WCAG 2.2 offiziell aufgenommen.</p>
<p>Wer digitale Angebote barrierefrei gestalten möchte, sollte diese Entwicklung bereits jetzt im Blick behalten. Eine zukunftssichere Planung berücksichtigt daher idealerweise schon heute die zusätzlichen Anforderungen der WCAG 2.2, insbesondere bei Neuentwicklungen, Relaunches oder größeren Anpassungen.</p>
<p>So lassen sich spätere Nachbesserungen vermeiden, Kosten einsparen und langfristige Konformität sicherstellen.</p>
<p>In den Bundesländern gelten eigene gesetzliche Bestimmungen. Dieses Dokument zeigt beispielhaft, wie die Erklärung zur Barrierefreiheit richtig und vollständig erstellt werden sollte.</p>
<p>Zur besseren Verständlichkeit findet ihr am Ende dieses Dokuments ein Glossar mit kurzen Erklärungen zentraler Begriffe rund um die folgenden Erklärungen.</p>
<h3 id="wcag-neue-anforderungen-der-wcag-22-neue-erfolgskriterien-der-wcag-22">Neue Erfolgskriterien der WCAG 2.2</h3>
<h4 id="wcag-neue-anforderungen-der-wcag-22-wahrnehmbar">Wahrnehmbar</h4>
<h5 id="wcag-neue-anforderungen-der-wcag-22-2411-fokus-nicht-verdeckt-minimum-stufe-aa">2.4.11 Fokus nicht verdeckt (Minimum) (Stufe AA):</h5>
<p>Der sichtbare Tastaturfokus darf nicht vollständig von anderen Elementen verdeckt sein. Das bedeutet: Wenn Nutzende mit der Tab-Taste durch Inhalte navigieren, muss das jeweils aktive Element immer mindestens teilweise sichtbar bleiben. Dies ist besonders relevant auf kleinen Bildschirmen oder bei feststehenden Layout-Bestandteilen (z. B. Sticky Header, Chatfenster).</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung">Umsetzungsempfehlung:</h6>
<p>Vermeidet es, dass sich fixierte oder überlagernde Elemente wie Cookie-Banner, Navigationsleisten oder Dialogfenster über fokussierte Inhalte legen. Prüft die Seite mit Tastaturnavigation (Tabulator-Taste) auf verschiedenen Bildschirmgrößen. Nutzt dabei Viewports bis 320 Pixel und stellt sicher, dass alle fokussierten Elemente sichtbar sind.</p>
<h5 id="wcag-neue-anforderungen-der-wcag-22-2413-fokus-sichtbar-stufe-aa">2.4.13 Fokus sichtbar (Stufe AA)</h5>
<p>Der Tastaturfokus muss für Nutzende deutlich erkennbar sein. Dies ist eine zentrale Voraussetzung für die Navigation mit Tastatur oder assistiven Technologien. Besonders auf mobilen Geräten oder bei schlechten Kontrastverhältnissen wird ein unsichtbarer oder kaum sichtbarer Fokus schnell zur Barriere.</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung-1">Umsetzungsempfehlung:</h6>
<p>Stellt über CSS sicher, dass fokussierte Elemente deutlich hervorgehoben werden, z. B. durch eine klare Umrandung, Schatten, Farbwechsel oder einen animierten Rahmen. Verwendet dabei ausreichende Kontraste und sorgt dafür, dass der Fokuszustand sich vom regulären Aussehen unterscheidet. Vermeidet es, den Fokusring global zu entfernen (z. B. durch outline: none), ohne eine gleichwertige Alternative zu bieten.</p>
<h5 id="wcag-neue-anforderungen-der-wcag-22-257-ziehende-bewegungen-stufe-aa">2.5.7 Ziehende Bewegungen (Stufe AA)</h5>
<p>Funktionen, die üblicherweise durch Ziehbewegungen (Drag & Drop) bedient werden, müssen auch ohne solche Bewegungen zugänglich sein. Dies betrifft etwa das Verschieben von Elementen in Formularen, Widgets oder Anwendungen.</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung-2">Umsetzungsempfehlung:</h6>
<p>Bietet eine Alternative zum Ziehen, etwa durch Schaltflächen wie „nach oben“ oder „nach unten verschieben“ oder Kontextmenüs mit Positionswahl an. In einer Bildergalerie sollte ein Bild nicht nur durch Drag & Drop neu angeordnet werden können, sondern auch per Tastatur durch Auswahl und Positionierung verschoben werden können. Dies ermöglicht die Nutzbarkeit für Menschen mit motorischen Beeinträchtigungen oder bei Touchscreen-Nutzung.</p>
<h5 id="wcag-neue-anforderungen-der-wcag-22-258-zielgröße-mindestmaß-stufe-aa">2.5.8 Zielgröße (Mindestmaß) (Stufe AA)</h5>
<p>Interaktive Elemente wie Buttons, Links oder Symbole müssen eine Mindestgröße von 24x24 CSS-Pixeln aufweisen, damit sie auch bei ungenauer Bewegung (z. B. mit dem Finger) zuverlässig aktiviert werden können.</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung-3">Umsetzungsempfehlung:</h6>
<p>Stellt sicher, dass alle klickbaren Bereiche diese Mindestgröße erreichen, entweder durch großzügige Padding-Werte oder größere aktive Flächen. Achtet darauf, dass auch kleine Icons oder Menüpunkte über ausreichend große Hotspots verfügen. Dies ist besonders für mobile Nutzende sowie für Personen mit motorischen Einschränkungen wichtig. Eine gute Praxis ist es, zusätzliche unsichtbare Bereiche, um kleine Icons herum klickbar zu machen, ohne das visuelle Layout zu verändern.</p>
<h4 id="wcag-neue-anforderungen-der-wcag-22-verständlichkeit">Verständlichkeit</h4>
<h5 id="wcag-neue-anforderungen-der-wcag-22-326-konsistente-hilfe-stufe-a">3.2.6 Konsistente Hilfe (Stufe A)</h5>
<p>Wenn eine Hilfe-Funktion angeboten wird, z. B. eine FAQ, ein Live-Chat, ein Support-Link oder ein telefonischer Kontakt, muss diese auf allen Seiten, auf denen sie zur Verfügung steht, an derselben Position erscheinen. Dies erleichtert die Orientierung, insbesondere für Menschen mit kognitiven Einschränkungen, Sehbeeinträchtigungen oder geringer Web-Erfahrung.</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung-4">Umsetzungsempfehlung:</h6>
<p>Bindet Hilfsangebote konsequent in die Hauptnavigation, Fußzeile oder eine klar benannte Seitenleiste ein. Platziert z. B. ein Hilfesymbol immer oben rechts im Header oder am unteren Rand der Seite unter „Kontakt und Hilfe“. Wiederholt die Platzierung auf allen relevanten Unterseiten. Achtet darauf, dass sich die Hilfe nicht nur inhaltlich, sondern auch in ihrer visuellen Darstellung nicht verändert. Dies stärkt das Vertrauen und die Wiedererkennbarkeit in die Funktion.</p>
<h5 id="wcag-neue-anforderungen-der-wcag-22-337-barrierefreie-authentifizierung-stufe-aa">3.3.7 Barrierefreie Authentifizierung (Stufe AA)</h5>
<p>Anmelde- oder Verifizierungsprozesse dürfen keine Barrieren für Menschen mit kognitiven oder sensorischen Beeinträchtigungen darstellen. Eine Authentifizierung muss auch dann möglich sein, wenn Nutzende Schwierigkeiten beim Merken, Verstehen oder visuellen Erfassen von Informationen haben.</p>
<h6 id="wcag-neue-anforderungen-der-wcag-22-umsetzungsempfehlung-5">Umsetzungsempfehlung:</h6>
<p>Vermeidet Verfahren, die allein auf visuelle Wahrnehmung oder komplizierte Denkvorgänge setzen, Bietet stattdessen barrierefreie Alternativen wie: passwortlose Anmeldung über Einmal-Links per E-Mail oder SMS, nutzbare 2-Faktor-Authentifizierung mit Sprachausgabe oder Tastaturbedienung, Invisible Captcha bei denen im Hintergrund das Nutzerverhalten auf der Website analysiert wird oder Unterstützung von Passwort-Manager-Funktionen durch saubere HTML-Eingabefelder mit autocomplete an.</p>
<h3 id="wcag-neue-anforderungen-der-wcag-22-geänderte-erfolgskriterien-der-wcag-22">Geänderte Erfolgskriterien der WCAG 2.2</h3>
<h4 id="wcag-neue-anforderungen-der-wcag-22-bedienbar">Bedienbar</h4>
<h5 id="wcag-neue-anforderungen-der-wcag-22-247-sichtbarer-fokus-stufe-a">2.4.7 Sichtbarer Fokus (Stufe A)</h5>
<p>Dieses Erfolgskriterium war bisher Teil der Konformitätsstufe AA und wurde mit WCAG 2.2 auf Stufe A hochgestuft. Das bedeutet: Ein sichtbarer Tastaturfokus ist nun eine absolute Mindestanforderung.</p>
<h4 id="wcag-neue-anforderungen-der-wcag-22-robust">Robust</h4>
<h5 id="wcag-neue-anforderungen-der-wcag-22-411-parsing-stufe-a">4.1.1 Parsing (Stufe A)</h5>
<p>Das Erfolgskriterium zum Parsing wurde in der WCAG 2.2 entfernt, da moderne Browser diese Aufgabe heute zuverlässig übernehmen. Beim Parsing geht es darum, dass der HTML-Code einer Webseite korrekt aufgebaut ist, damit er von Browsern und assistiven Technologien richtig interpretiert werden kann. Früher war es notwendig, strenge Regeln für den Quellcode einzuhalten, um sicherzustellen, dass Inhalte vollständig und korrekt dargestellt werden. Heute erkennen und korrigieren aktuelle Browser kleinere Fehler automatisch, sodass dieser Standard als eigenständiges Erfolgskriterium nicht mehr erforderlich ist.</p>
<h3 id="wcag-neue-anforderungen-der-wcag-22-tools-zur-prüfung-der-wcag-anforderungen-22">Tools zur Prüfung der WCAG-Anforderungen 2.2</h3>
<h4 id="wcag-neue-anforderungen-der-wcag-22-tollwerk-bookmarklet-fokus-sichtbar">Tollwerk Bookmarklet: Fokus sichtbar</h4>
<p>Hebt visuell den aktuellen Tastaturfokus hervor.</p>
<p>Link: <a href="https://bkmrk.tollwerk.de/focus-visible">https://bkmrk.tollwerk.de/focus-visible</a></p>
<h4 id="wcag-neue-anforderungen-der-wcag-22-tollwerk-bookmarklet-fokus-reihenfolge">Tollwerk Bookmarklet: Fokus-Reihenfolge</h4>
<p>Zeigt Tab-Reihenfolge und verdeckte Fokusprobleme.</p>
<p>Link: <a href="https://bkmrk.tollwerk.de/focus-order">https://bkmrk.tollwerk.de/focus-order</a></p>
<h4 id="wcag-neue-anforderungen-der-wcag-22-wave-evaluation-tool">WAVE Evaluation Tool</h4>
<p>Prüft Fokusanzeige, Semantik und Eingabehilfen. Visualisiert zugängliche Inhalte direkt im Browser.</p>
<p>Link: <a href="https://wave.webaim.org">https://wave.webaim.org</a></p>
<p>Diese Liste erhebt nicht den Anspruch vollständig zu sein, es gibt noch viele andere Tools und Werkzeuge. Dies ist lediglich ein Einstieg.</p>
<h3 id="wcag-neue-anforderungen-der-wcag-22-glossar">Glossar</h3>
<ul>
<li><p><strong>Assistive Technologien</strong>: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe, die Menschen mit Beeinträchtigungen die Nutzung digitaler Inhalte ermöglichen.</p></li>
<li><p><strong>Autocomplete</strong>: Eine Funktion in Formularfeldern, die Eingaben automatisch vervollständigt oder vorschlägt, basierend auf vorherigen Eingaben oder gespeicherten Daten.</p></li>
<li><p><strong>Authentifizierungsverfahren</strong>: Methoden zur Identitätsbestätigung, z. B. Passwort, Fingerabdruck oder Zwei-Faktor-Authentifizierung. Sie müssen auch für Menschen mit Beeinträchtigungen nutzbar sein.</p></li>
<li><p><strong>BFSG</strong>: Barrierefreiheitsstärkungsgesetz.</p></li>
<li><p><strong>BITV</strong>: Barrierefreie-Informationstechnik-Verordnung.</p></li>
<li><p><strong>Browser</strong>: Programme zur Darstellung von Webseiten, z. B. Firefox, Chrome, Safari oder Edge.</p></li>
<li><p><strong>Captcha</strong>: Automatisierte Tests zur Unterscheidung zwischen Menschen und Maschine. Sollten barrierefrei gestaltet oder durch zugängliche Alternativen ersetzt werden.</p></li>
<li><p><strong>Cookie-Banner</strong>: Einblendungen zur Zustimmung von Cookies. Sie müssen per Tastatur bedienbar und für Screenreader zugänglich sein.</p></li>
<li><p><strong>CSS (Cascading Style Sheets)</strong>: Sprache zur Gestaltung von HTML-Inhalten, z. B. für Farben, Abstände, Schriftgrößen und Layout.</p></li>
<li><p><strong>Drag & Drop</strong>: Interaktive Bedienmethode durch Ziehen und Ablegen. Muss auch per Tastatur oder alternativen Eingabemethoden zugänglich sein.</p></li>
<li><p><strong>HTML</strong>: Hypertext Markup Language. Strukturierungssprache für Webseiteninhalte.</p></li>
<li><p><strong>Hotspots</strong>: Interaktive Bereiche auf Bildern oder Karten. Müssen programmatisch zugänglich und alternativ beschreibbar sein.</p></li>
<li><p><strong>Javascript</strong>: Skriptsprache zur Umsetzung dynamischer Inhalte und Interaktionen auf Webseiten. Muss barrierefrei integriert und steuerbar sein.</p></li>
<li><p><strong>Outline</strong>: Der Fokusrahmen, der bei Tastaturnavigation sichtbar wird. Er sollte nicht entfernt, sondern gestalterisch angepasst werden.</p></li>
<li><p><strong>Padding</strong>: Innenabstand zwischen Inhalt und Rand eines Elements. Wichtig für die optische Lesbarkeit und Bedienbarkeit.</p></li>
<li><p><strong>Parsing</strong>: Verarbeitung und Interpretation des HTML-Codes durch den Browser. Früher war korrektes Parsing Voraussetzung für Barrierefreiheit. Moderne Browser erkennen kleinere Fehler meist automatisch.</p></li>
<li><p><strong>Pixel</strong>: Maßeinheit für die Bildschirmdarstellung. Barrierefreie Gestaltung sollte flexibel auf verschiedene Pixelgrößen reagieren.</p></li>
<li><p><strong>Programmatisch</strong>: Bezieht sich auf Informationen, die maschinell ausgelesen werden können, z. B. von Screenreadern.</p></li>
<li><p><strong>Quellcode/Quelltext</strong>: Gesamtheit des für eine Anwendung geschriebenen Codes (z. B. HTML, CSS, JavaScript). Grundlage für die technische Barrierefreiheit.</p></li>
<li><p><strong>Sticky Header</strong>: Fixierte Kopfzeile, die beim Scrollen sichtbar bleibt. Muss korrekt mit dem Fokus durch Tab-Taste erreichbar sein.</p></li>
<li><p><strong>Tab-Taste / Tabulatortaste</strong>: Zentrale Taste zur Navigation per Tastatur. Damit werden fokussierbare Elemente der Reihe nach angesteuert.</p></li>
<li><p><strong>UX-Design (User Experience Design)</strong>: Gestaltungsansatz, der auf gute Benutzerführung, Verständlichkeit und barrierefreie Bedienbarkeit abzielt.</p></li>
<li><p><strong>Viewport</strong>: Der sichtbare Bereich einer Webseite im Browserfenster. Wichtig für die Darstellung auf verschiedenen Geräten.</p></li>
<li><p><strong>WCAG (Web Content Accessibility Guidelines)</strong>: Internationale Richtlinien zur digitalen Barrierefreiheit.</p></li>
</ul>
<h2 id="barrierefreie-alternativtexte-schreiben-so-gehts">Barrierefreie Alternativtexte schreiben: So geht´s!</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/alternativtexte.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_alternativtexte.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../alternativtexte/image2.jpeg" style="" alt="Eine grauhaarige Katze sitzt auf einem Tisch neben einer Vase mit leuchtend pinken Pfingstrosen. Die Katze blickt aufmerksam in die Kamera, während das Licht durch das Fenster danebenfällt" />
<p><strong>Schlechter Alternativtext</strong>: Picture1.jpg – Vase mit Blume und Katze</p>
<p><strong>Guter Alternativtext</strong>: Eine grauhaarige Katze sitzt auf einem Tisch neben einer Vase mit leuchtend pinken Pfingstrosen. Die Katze blickt aufmerksam in die Kamera, während das Licht durch das Fenster danebenfällt</p>
<h3 id="barrierefreie-alternativtexte-schreiben-so-gehts-alternativtexte-schreiben">Alternativtexte schreiben</h3>
<ul>
<li><p>Beschreibe den Inhalt des Bildes: Was ist auf dem Bild zu sehen?<br>
Welche Information vermittelt es?</p></li>
<li><p>Wichtiges zuerst: Beginne den Alternativtext mit den wichtigsten<br>
Informationen.</p></li>
<li><p>Kontext berücksichtigen: Überlege, wie das Bild im Kontext des<br>
gesamten Textes oder der Seite verwendet wird.</p></li>
<li><p>Kurz und prägnant: Wir empfehlen höchstens 80 Zeichen, da das<br>
die maximale Textlänge ist, die beim Navigieren mit einer Braillezeile<br>
auf einmal wahrnehmbar ist.</p></li>
<li><p>Relevant: Der Alternativtext sollte den Zweck des Bildes in Bezug auf<br>
den gesamten Inhalt beschreiben.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-vermeidung-typischer-fehler">Vermeidung typischer Fehler</h4>
<ul>
<li><p><strong>Keine Dateinamen als Alternativtext</strong>: Verwende nicht den Dateinamen des Bildes als Alternativtext (z. B. „bild123.jpg“).</p></li>
<li><p><strong>Vermeide unnötige Worte</strong>: Es ist nicht notwendig, „Bild von...“ oder<br>
„Foto von...“ zu schreiben, da Screenreader dies bereits vermitteln.</p></li>
<li><p><strong>Zusatzinformationen</strong>, wie z. B. Angaben zum Urheberrecht sind nicht<br>
Bestandteil eines Alternativtextes.</p></li>
<li><p><strong>Vermeide Redundanzen</strong>: Wenn das Bild nur dekorativ ist und keine<br>
zusätzliche Information bietet, sollte es ebenso gekennzeichnet werden</p></li>
</ul>
<h3 id="barrierefreie-alternativtexte-schreiben-so-gehts-komplexe-bilder">Komplexe Bilder</h3>
<ul>
<li><p><strong>Diagramme und Grafiken</strong>: Gib eine kurze Zusammenfassung als Alternativtext und<br>
biete zusätzlich eine ausführlichere Beschreibung im Text oder<br>
in einer separaten Datei an.</p></li>
<li><p><strong>Gruppierte Bilder</strong>: Bei mehreren zusammenhängenden Bildern, die<br>
eine Geschichte erzählen, kann der Alternativtext die Bildreihe im<br>
Kontext beschreiben.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-technische-umsetzung">Technische Umsetzung</h4>
<ul>
<li><p><strong>HTML</strong>: Verwende das alt-Attribut innerhalb des <code>img-Tags</code>, z. B.<br>
<code>;img src="bild.jpg" alt="Beschreibung des Bildes"></code>. Alternativtexte<br>
werden über das „alt“ Attribut gesetzt. Ein leeres „alt“ Attribut (alt="") markiert die Grafik als dekorativ, sodass diese von assistiven Technologien<br>
nicht mehr ausgegeben wird.</p></li>
<li><p><strong>Content-Management-Systeme (CMS)</strong>: Die meisten CMS (z. B. WordPress,<br>
Drupal) bieten eine einfache Möglichkeit, Alternativtexte beim Hochladen<br>
von Bildern hinzuzufügen.</p></li>
<li><p><strong>Social Media</strong>: Plattformen wie LinkedIn, Twitter und Facebook bieten<br>
spezielle Felder zum Hinzufügen von Alternativtexten beim Posten von<br>
Bildern an.</p></li>
</ul>
<h3 id="barrierefreie-alternativtexte-schreiben-so-gehts-checkliste">Checkliste</h3>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-inhaltliche-beschreibung">Inhaltliche Beschreibung</h4>
<ul>
<li><p>Schreibe einen Alternativtext, der die wesentlichen visuellen Elemente des Bildes beschreibt.</p></li>
<li><p>Achte darauf, dass der Alternativtext die wesentliche Botschaft oder den Zweck des Bildes vermittelt.</p></li>
<li><p>Beschränke dich auf die wichtigen Details, die für das Verständnis notwendig sind.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-länge-und-prägnanz">Länge und Prägnanz</h4>
<ul>
<li><p>Formuliere den Alternativtext so kurz wie möglich, ohne wichtige Informationen auszulassen. (max. 80 Zeichen)</p></li>
<li><p>Verwende vollständige Sätze, wenn sie die Verständlichkeit verbessern, aber sei nicht zu langatmig.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-relevante-details-einfügen">Relevante Details einfügen</h4>
<ul>
<li><p>Stelle sicher, dass wichtige Details, die für den Inhalt relevant sind, im Alternativtext enthalten sind.</p></li>
<li><p>Verzichte auf Informationen, die für das Verständnis des Bildes nicht notwendig sind.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-fehlerquellen-vermeiden">Fehlerquellen vermeiden</h4>
<ul>
<li><p>Verwende keine Dateinamen, Copyright-Informationen oder ähnliche Angaben im Alternativtext.</p></li>
<li><p>Der Alternativtext sollte direkt zur Bildbeschreibung übergehen, ohne überflüssige Einleitungen.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-kontextuelle-anpassung">Kontextuelle Anpassung</h4>
<ul>
<li><p>Überlege, ob der Alternativtext für den spezifischen Kontext (z. B. Blog, Social Media) geeignet ist.</p></li>
<li><p>Bei rein dekorativen Bildern ein leeres Alt-Attribut (alt="") verwenden, um den Alternativtext zu überspringen.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-verständlichkeit-prüfen">Verständlichkeit prüfen</h4>
<ul>
<li><p>Lies den Alternativtext laut vor, um sicherzustellen, dass er verständlich und sinnvoll ist.</p></li>
<li><p>Überprüfe den Alternativtext mit einem Screenreader, um seine Nutzbarkeit für Menschen mit Sehbehinderungen zu testen.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-kontinuität-und-konsistenz-sicherstellen">Kontinuität und Konsistenz sicherstellen</h4>
<ul>
<li><p>Achte darauf, dass Alternativtexte innerhalb eines Projekts oder einer Seite konsistent gestaltet sind.</p></li>
<li><p>Überprüfe Alternativtexte regelmäßig auf Aktualität und Relevanz.</p></li>
</ul>
<h4 id="barrierefreie-alternativtexte-schreiben-so-gehts-zusätzliche-schritte-für-komplexe-inhalte">Zusätzliche Schritte für komplexe Inhalte</h4>
<ul>
<li><p>Erstelle für komplexe Grafiken eine kurze, prägnante Zusammenfassung im Alternativtext und verweise auf detailliertere Beschreibungen im Text.</p></li>
<li><p>Wenn das Bild verlinkt ist, sollte der Alternativtext den Zweck des Links oder die Zielseite beschreiben.</p></li>
</ul>
<h2 id="barrierefreie-links">Barrierefreie Links</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/barrierefreielinks.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_links.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../barrierefreie-links/undraw_link-shortener_9ro5__1_.png" style="" alt="" />
<h3 id="barrierefreie-links-barrierefreie-links-was-heißt-das">Barrierefreie Links! Was heißt das?</h3>
<p>Habt ihr schon einmal auf einer Webseite nur <strong>"Hier klicken"</strong> als Linktext gesehen und euch gefragt, wohin der Link führt? Solche vage formulierten Links können für viele Nutzende zum Stolperstein werden. Wir zeigen euch, warum aussagekräftige Linktexte wichtig sind und wie ihr Links in Webseiten und Dokumenten so gestaltet, dass diese für alle zugänglich sind!</p>
<h3 id="barrierefreie-links-warum-sind-barrierefreie-links-wichtig">Warum sind barrierefreie Links wichtig?</h3>
<p>Barrierefreie Links helfen Menschen mit unterschiedlichen Einschränkungen sowie allen anderen Nutzenden, sich besser in digitalen Inhalten zurechtzufinden. Sehbeeinträchtigte Menschen nutzen oft Linklisten und springen oft von Link zu Link (um sich eine Übersicht über die Inhalte der Seite zu verschaffen), der Screenreader liest dann nur die Linktexte vor. Deshalb muss der Linktext deutlich machen, worum es bei dem Link geht und wohin er führt. Ist der Zweck eines Links allein am Linktext erkennbar, können sehbeeinträchtigte Nutzende sofort entscheiden, ob sie diesem folgen möchten. Das WCAG- Erfolgskriterium 2.4.4 („Linkzweck im Kontext“) fordert genau dies: Der Zweck jedes Links soll aus dem Linktext (ggf. mit dessen unmittelbarem Kontext) hervorgehen.</p>
<p>Auch Menschen mit motorischen Beeinträchtigungen profitieren: Sie navigieren häufig per Tastatur durch Webseiten. Für sie ist es wichtig zu sehen, welcher Link gerade fokussiert ist. Daher sollten Links beim Fokus visuell hervorgehoben sein (z. B. durch Unterstreichung oder farbliche Umkehr). Wichtig: <strong>Farbe allein</strong> darf nie das einzige Erkennungsmerkmal für einen Link sein. Personen mit Farbsehschwäche könnten rein farbige Hervorhebungen übersehen, daher sollte immer auch eine Unterstreichung oder ein Symbol als Hinweis auf Links dienen. Kurzum: Barrierefreie Links sind keine exotische Kür, sondern nützen allen, sie verbessern Orientierung, Verständlichkeit und Benutzerfreundlichkeit für die gesamte Zielgruppe.</p>
<h3 id="barrierefreie-links-verständliche-linktexte">Verständliche Linktexte</h3>
<p>Der Schlüssel zu barrierefreien Links liegt im Linktext. Ein guter Linktext ist sprechend und selbsterklärend, er beschreibt, was einem nach dem Klick erwartet. Vermeidet generische Formulierungen wie <strong>„Hier klicken“, „Mehr“, „Weiter“</strong> oder lange URLs. Solche Begriffe sind für sich genommen nicht aussagekräftig und verwirren Nutzende, insbesondere wenn mehrere gleichlautende Links auf einer Seite vorkommen. Besser ist es, den Linktext so zu formulieren, dass Zweck oder Ziel des Links klar werden.</p>
<p>Stellt euch vor, ein Screenreader liest eurem Publikum nur die Linktexte eurer Seite vor, würde man daraus den Inhalt und das Ziel der Links verstehen? Wenn nicht, überarbeitet die Texte. Idealerweise kann der Linktext im Kontext gelesen werden, ist aber auch allein verständlich.</p>
<p>Zum Beispiel statt <strong>„Hier klicken für den Bericht“</strong> lieber <strong>„Bericht 2024 als PDF herunterladen“</strong>, so weiß jeder sofort, was ihn erwartet. Einheitlichkeit hilft ebenfalls: Verlinkt die Kontaktseite immer mit demselben Linktext <strong>„Kontakt“</strong>, anstatt mal <strong>„Kontakt“</strong>, mal <strong>„Schreiben Sie uns“</strong> zu schreiben.</p>
<h4 id="barrierefreie-links-tipp">Tipp</h4>
<p>Wenn auf Dateien wie PDF oder Word verlinkt wird, erwähnt das Format direkt im Linktext. Nutzende sollten vorab wissen, dass sie beispielsweise ein PDF öffnen, da hierfür möglicherweise ein anderes Programm oder Plugin benötigt wird. Schreit also „Antragsformular (PDF)“ anstatt nur „Antragsformular“. So werden Überraschungen verhindert, Nutzende sind nicht irritiert, wenn plötzlich PDF-Funktionen statt der gewohnten Browser-Funktionen erscheinen.</p>
<h3 id="barrierefreie-links-links-in-html-richtig-umsetzen">Links in HTML richtig umsetzen</h3>
<p>Auf Webseiten werden Links mit dem <code><a></code>-Element erstellt. Achtet darauf, den Linktext sinnvoll zu wählen und das Markup korrekt einzusetzen. Ein einfacher HTML-Link mit gutem Linktext könnte so aussehen:</p>
<p><code><a href="bericht2024.pdf">Bericht 2024 (PDF, 2 MB)</a></code></p>
<p>In diesem Beispiel ist „Bericht 2024 (PDF, 2 MB)“ der aussagekräftige Linktext, der sowohl den Inhalt (Bericht 2024) als auch das Dateiformat PDF angibt. Nutzende wissen damit genau, was sie erwartet. Verzichtet darauf, den Linktext als leeren Platzhalter zu lassen.</p>
<p>Wenn Symbole oder Icons verwendet werden (PDF-Icon vor dem Linktext), verseht diese mit einem Alternativtext, der das Format angibt (etwa <code>alt="PDF"</code> beim Icon). Alternativ kann auch ein <code>title</code>-Attribut am Link zusätzliche Hinweise geben (<code>title="öffnet als PDF-Datei"</code>), jedoch sollte der Hauptlinktext bereits ausreichend informieren. Verzichtet bei der Umsetzung auf Doppelungen, sollte ein Icon verwendet werden und die Angabe des Dateiformats steht im Linktext oder title Attribut, muss das Icon als dekorativ gekennzeichnet werden.</p>
<p>Bei verlinkten Bildern ist der <code>alt</code>-Text entscheidend. Dieser sollte sowohl den Inhalt des Bildes als auch das Linkziel enthalten. Beispiel: Ein verlinktes Behördenlogo könnte <code>alt="Logo der Stadt Musterhausen – zur Website der Stadt Musterhausen"</code> haben. So erfassen Screenreader-Nutzende sofort, wohin der Klick auf das Logo führt.</p>
<p>Und nicht zuletzt: Stellt sicher, dass alle Links per Tastatur erreichbar sind. In HTML heißt das, verwendet echte <code><a></code>-Elemente (oder Schaltflächen für Aktionen), denn diese sind von Natur aus per Tab-Taste fokussierbar. Prüft eure Webseite, indem ihr wiederholt die Tabulatortaste drückt:</p>
<ul>
<li><p>Erreicht der Fokus jeden Link der Seite in sinnvoller Reihenfolge?</p></li>
<li><p>Ist der fokussierte Link immer visuell erkennbar (Durch Unterstreichung oder Rahmen) und nicht verdeckt?</p></li>
</ul>
<p>Nur bedienbare Links sind barrierefreie Links.</p>
<h3 id="barrierefreie-links-links-in-dokumenten">Links in Dokumenten</h3>
<p>Barrierefreie Links sind nicht nur im Web wichtig, sondern auch in PDF- und Word-Dokumenten. PDF-Dateien werden oft aus Word heraus erstellt, hier gilt:</p>
<p>Was in Word falsch läuft, wird im PDF nicht besser.</p>
<p>Nutzt daher in Word konsequent die Hyperlink-Funktion, anstatt einfach nur URLs ins Dokument zu schreiben. Markiert den beschreibenden Text und fügt dann über <strong>Einfügen → Link</strong> den Hyperlink ein. So wird sichergestellt, dass im PDF später ein richtig getaggter Link mit sinnvoller Beschriftung vorhanden ist.</p>
<p>Der Linktext im Dokument sollte ebenso aussagekräftig sein wie im Web: also keine nackten URLs wie <code>http://...</code> im Fließtext, und keine Platzhaltertexte wie „hier“. Schreibt statt <code>https://www.mustermann.de/barrierefreiheit</code> lieber „Webauftritt der Muster-Behörde zur Barrierefreiheit“ und hinterlegt den Hyperlink. Das sieht nicht nur sauber aus, sondern verhindert, dass Screenreader jeden einzelnen Buchstaben einer URL vorlesen, was sehr mühsam sein kann. Ein klarer Linktext umgeht dieses Problem.</p>
<h3 id="barrierefreie-links-optische-gestaltung-von-links">Optische Gestaltung von Links</h3>
<p>Eine angemessene optische Gestaltung von Links ist ein zentraler Baustein barrierefreier digitaler Inhalte. Die optische Gestaltung betrifft Farbe, Kontrast, Struktur und Fokus-Indikatoren und orientiert sich an anerkannten Richtlinien wie den Web Content Accessibility Guidelines (WCAG).</p>
<p>Barrierefreie Links müssen sich klar vom umgebenden Text abheben. Die bloße Unterscheidung durch Farbe reicht nicht aus, wenn sie das einzige visuelle Merkmal ist, denn nicht alle Menschen können Farbunterschiede zuverlässig wahrnehmen. Neben der Farbe braucht es zusätzliche visuelle Hinweise wie Unterstreichung oder andere Markierungen, um den Link visuell zu kennzeichnen.</p>
<p>Für die Lesbarkeit von Linktexten sind Farbkontraste zwischen Text und Hintergrund, aber auch im Vergleich zum umgebenden Text relevant. Die WCAG definieren Mindestkontrastwerte, die für gut lesbaren Text einzuhalten sind: Normaler Text sollte einen Kontrast von mindestens 4,5:1 gegenüber dem Hintergrund haben. Größere oder stärker gewichtete Texte (z. B. ≥18 pt oder ≥14 pt fett) benötigen einen Kontrastwert von mindestens 3:1.</p>
<p>Ein Link muss auch bei Tastaturfokus klar erkennbar sein. Das heißt, wenn Nutzende per Tabulator durch Links navigieren, muss jederzeit klar erkennbar sein, welche Komponente den aktuellen Fokus hat. Der Fokus-Indikator sollte dabei so gestaltet werden, dass er sichtbar und gut erkennbar ist, etwa durch einen deutlich hervorgehobenen Rahmen oder eine kontrastreiche Hervorhebung um den Linktext bzw. das Element.</p>
<p>Das visuelle Erscheinungsbild von Links sollte innerhalb eines Angebots konsistent sein. Einheitliche Farben, Unterstreichungen und Fokusstile erleichtern allen Nutzenden die Orientierung.</p>
<h3 id="barrierefreie-links-beispiele-gute-und-schlechte-linkformulierungen">Beispiele: Gute und schlechte Linkformulierungen</h3>
<p>Zum Abschluss ein paar konkrete Beispiele, die zeigen, wie man Linktexte verbessern kann:</p>
<h4 id="barrierefreie-links-beispiel-1">Beispiel 1</h4>
<p><strong>Schlechtes Beispiel</strong>: <em>„Hier klicken für mehr Infos“</em> – Dieser Linktext ist isoliert betrachtet nichtssagend. Nutzer wissen nicht, welche Info sie erwartet.
<strong>Besser</strong>: <em>„Mehr Infos zur Barrierefreiheit im Web“</em> – Der Zweck des Links wird klar (führt zu Informationen über Web-Barrierefreiheit).
<img src="../barrierefreie-links/beispiel1.png" style="" alt="Screenshot Beispiel 1" /></p>
<h4 id="barrierefreie-links-beispiel-2">Beispiel 2</h4>
<p><strong>Schlechtes Beispiel</strong>: <em>„Download“</em> (als einziger Linktext neben einem Dateisymbol) – Hier fehlt die Angabe, <strong>was</strong> heruntergeladen wird.
<strong>Besser</strong>: <em>„Leitfaden Barrierefreie PDFs herunterladen (PDF, 1 MB)“</em> – Der Link nennt den Dokumenttitel und das Format, so wissen alle Bescheid
<img src="../barrierefreie-links/beispiel2.PNG" style="" alt="Screenshot Beispiel 2" /></p>
<h4 id="barrierefreie-links-beispiel-3">Beispiel 3</h4>
<p><strong>Schlechtes Beispiel</strong>: Eine Liste voller unbeschrifteter URLs: <em>„https://www.beispiel.de/a/12345“</em> … – Für Sehende unübersichtlich und für Screenreader-Nutzende extrem mühsam, da jeder Buchstabe einzeln vorgelesen wird.
<strong>Besser</strong>: Eine Liste mit klaren Textlinks: <em>„Online-Antrag auf Wohngeld stellen“</em>, <em>„Informationen zum Familienbonus“</em> etc. – Aussagekräftig und verständlich vorlesbar.
<img src="../barrierefreie-links/beispiel3.png" style="" alt="Screenshot Beispiel 3" /></p>
<p>Diese Beispiele verdeutlichen: Klartext im Link macht den Unterschied zwischen Verwirrung und Bedienbarkeit.</p>
<h3 id="barrierefreie-links-checkliste-barrierefreie-links-in-webseiten-und-dokumenten">Checkliste: Barrierefreie Links in Webseiten und Dokumenten</h3>
<h4 id="barrierefreie-links-allgemeine-regeln">Allgemeine Regeln</h4>
<ul>
<li><p>Linkzweck erkennbar: Jeder Linktext beschreibt klar, wohin der Link führt („Leitfaden Barrierefreiheit (PDF)“ statt „Hier klicken“).</p></li>
<li><p>Keine doppelten Linktexte: Mehrere Links mit demselben Text führen auch wirklich zum selben Ziel. Wenn nicht, müssen sie unterschiedlich heißen.</p></li>
<li><p>Keine reinen URLs im Fließtext: Links bestehen aus lesbarem, beschreibendem Text, nicht aus „https://…“-Adressen.</p></li>
<li><p>Dateiformat und Größe genannt: Bei Downloads steht das Format („PDF“, „DOCX“) und möglichst auch die Dateigröße im Linktext.</p></li>
<li><p>Konsistente Benennung: Gleichartige Ziele heißen überall gleich – z. B. immer „Kontaktformular“ und nicht mal „Kontaktseite“, mal „Kontakt aufnehmen“.</p></li>
</ul>
<h4 id="barrierefreie-links-für-webseiten-html">Für Webseiten (HTML)</h4>
<ul>
<li><p>Echte <code>a-Elemente</code> verwendet: Keine Pseudo-Links mit JavaScript oder <code>div role="link"</code>.</p></li>
<li><p>Sprechender Linktext: Im Code steht: <code> <a href="bericht2024pdf">Bericht 2024 (PDF, 2 MB);/a></code></p></li>
<li><p>Fokus sichtbar: Beim Tabben durch die Seite ist immer klar erkennbar, welcher Link gerade aktiv ist.</p></li>
<li><p>Keine Farbe allein: Links sind zusätzlich unterstrichen oder auf andere Weise gekennzeichnet, nicht nur farblich.</p></li>
<li><p>Gute Erkennbarkeit: Links werden konsistent auf der gesamten Website mit gutem Kontrast präsentiert.</p></li>
<li><p>Bild-Links haben Alt-Text: Das Alt-Attribut enthält sowohl den Bildinhalt als auch das Linkziel ( alt="Logo der Stadt – zur Startseite").</p></li>
</ul>
<h4 id="barrierefreie-links-für-dokumente-word--pdf">Für Dokumente (Word & PDF)</h4>
<ul>
<li><p>Hyperlink-Funktion genutzt: Links werden über „Einfügen → Link“ erstellt, nicht als reine URL getippt.</p></li>
<li><p>Aussagekräftiger Text: Statt „www.bfit-bund.de“ lieber „Website der BFIT-Bund“ als Linktext verwenden.</p></li>
<li><p>QuickInfo (ScreenTip) gesetzt: Kurzer Hinweis zum Linkziel („Öffnet in neuem Fenster“) kann ergänzend angegeben werden.</p></li>
<li><p>Struktur-Tags im PDF enthalten: Beim Export auf „Dokumentstruktur-Tags für Barrierefreiheit“ achten.</p></li>
</ul>
<h4 id="barrierefreie-links-selbsttest">Selbsttest</h4>
<ul>
<li><p>Tab-Test bestanden: Alle Links sind per Tastatur erreichbar und der Fokus ist klar erkennbar.</p></li>
<li><p>Screenreader-Test: Beim Vorlesen der „Linkliste“ sind alle Links verständlich (kein mehrfaches „Hier klicken“).</p></li>
<li><p>Kontext verständlich: Würde der Linktext auch ohne umgebenden Text Sinn ergeben? Wenn ja → gut gemacht.</p></li>
</ul>
<h3 id="barrierefreie-links-weiterführende-informationen-und-tools">Weiterführende Informationen und Tools</h3>
<ul>
<li><p>BIK-BITV-Test: <a href="https://bitvtest.de/bitvtest/das_testverfahren_im_detail/pruefschritt_2.4.4.html">WCAG 2.1, Erfolgskriterium 2.4.4 „Linkzweck (im Kontext)</a></p></li>
<li><p>Bundesfachstelle Barrierefreiheit: <a href="https:/www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/Barrierefreie-Webseiten/barrierefreie-webseiten.html">Fachwissen IT</a></p></li>
</ul>
<h2 id="barrierefreie-textgestaltung-in-user-interface-elementen">Barrierefreie Textgestaltung in User-Interface-Elementen</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/barrierefreietextgestaltunguie.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_barrierefreie-textgestaltung-uie.pdf">PDF Datei</a> heruntergeladen werden.
<img src="../barrierefreie-textgestaltung-uie/image2.png" style="" alt="" /></p>
<p>Barrierefreie Textgestaltung ist ein zentraler Bestandteil digitaler Zugänglichkeit. Sie sorgt dafür, dass Inhalte für möglichst viele Menschen verständlich, lesbar und nutzbar sind, unabhängig von Sehvermögen, Gerät oder Assistenztechnologie.</p>
<p>Die Gestaltung eines Textes besteht im Wesentlichen aus Schrift und Formatierung. Dieser Leitfaden konzentriert sich auf die Darstellung von Textelementen innerhalb einer Website oder Softwareanwendung. Dabei handelt es sich genauer gesagt um Textinformationen von User-Interface-Elementen. User-Interface-Elemente sind sichtbare und bedienbare Bestandteile einer digitalen Benutzeroberfläche, mit denen Menschen mit einer Software, Webseite oder App interagieren. Dazu gehören beispielsweise Formate wie Fließtexte, Beschreibungen oder Beschriftungen, aber auch Buttons, Textfelder, Menüs, Links oder Tabellen.</p>
<p>Damit Textinformationen von möglichst vielen Menschen wahrgenommen werden können, gibt es hinsichtlich Schrift und Formatierung konkrete Empfehlungen. Die Handreichung <a href="https://handreichungen.bfit-bund.de/barrierefreie-uie">Barrierefreie Gestaltung von User Interface-Elementen</a> der AG Software des Ausschusses für barrierefreie Informationstechnik listet zu diesem Thema genaue Anforderungen auf, die wir für die nachfolgende Aufzählung mit Infos aus dem Wissensportal <a href="https://www.leserlich.info">leserlich.info</a> ergänzt haben.</p>
<h3 id="barrierefreie-textgestaltung-in-user-interface-elementen-hinweis">Hinweis</h3>
<p>In diesem Leitfaden steht die barrierefreie Gestaltung (Schrift und Formatierung) von Textelementen auf Websites und in Softwareanwendungen im Mittelpunkt, nicht die Textgestaltung in Dokumenten in Anwendungen wie beispielsweise Microsoft Word oder Open Office. Die hier aufgezählten Anforderungen sind dennoch in vielen Punkten vergleichbar mit denen für Dokumente.</p>
<p>Der Leitfaden richtet sich insbesondere an Menschen, die in der Softwareentwicklung, in Webredaktionen oder Designteams arbeiten oder Barrierefreiheitstests durchführen.</p>
<h3 id="barrierefreie-textgestaltung-in-user-interface-elementen-rechtliche-einordnung-der-empfehlungen">Rechtliche Einordnung der Empfehlungen</h3>
<p>Die folgenden Empfehlungen bestehen zum einen aus Mindestanforderungen aus der EN 301 549, die erfüllt sein müssen, um mit der BITV 2.0 konform zu sein. Darüber hinaus enthalten die untenstehenden Empfehlungen weitergehende Anforderungen aus der WCAG 2.1. Im Sinne der gesellschaftlichen Teilhabe ist es empfehlenswert, nicht nur ein Mindestmaß an digitaler Barrierefreiheit zu erfüllen, sondern gemäß § 3 Abs. 4 BITV 2.0 für bestimmte Anwendungsbereiche ein höchstmögliches Maß der Barrierefreiheit anzustreben:</p>
<p>„Für zentrale Navigations- und Einstiegsangebote sowie Angebote, die eine Nutzerinteraktion ermöglichen, beispielsweise Formulare und die Durchführung von Authentifizierungs-, Identifizierungs- und Zahlungsprozessen, soll ein höchstmögliches Maß an Barrierefreiheit angestrebt werden“.
Die Zuordnung der einzelnen Anforderungen und Empfehlungen zu ihren jeweiligen Stellen in der EN 301 549 bzw. WCAG 2.1 ist hier aufgeführt: <a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/schrift.html">Schrift - Barrierefreie Gestaltung von User Interface-Elementen</a>.</p>
<h3 id="barrierefreie-textgestaltung-in-user-interface-elementen-empfehlungen-für-barrierefreie-textgestaltung">Empfehlungen für barrierefreie Textgestaltung</h3>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-schriftart">Schriftart</h4>
<p>Humanistische serifenlose Schriften gelten als am besten lesbar und eignen sich daher gut für barrierefreie Texte. Humanistische Schriftarten mit ihren runden, offenen Formen entspringen vereinfacht gesagt einer Gegenbewegung zur engen gotischen Schrift des Mittelalters.</p>
<img src="../barrierefreie-textgestaltung-uie/image3.png" style="" alt="Vergleich der offenen Buchstabenformen in den Schriftarten Verdana, Lucida Sans und Calibri; besonders offene Buchstaben wie a,e und c sind mit Pfeilen markiert." />
<p>Die serifenlosen Varianten kommen ohne die kleinen, dekorativen Querstriche aus, die die Enden der Buchstabenstriche abschließen. Ihr Vorteil ist, dass sie häufig bereits über ausreichend Zeichenabstand verfügen (der Abstand zwischen den Buchstaben innerhalb eines Wortes) und eine offene Form haben. Das bedeutet, dass Buchstaben wie beispielsweise a, c, e, o, s und g weite Innenräume haben. Diese Buchstabenform erhöht die Unterscheidbarkeit der einzelnen Zeichen voneinander und damit die Lesbarkeit.
So können auch bei schlechtem Sehvermögen oder ungünstigen Lichtverhältnissen Texte besser wahrgenommen werden. Eine gute Schrift sorgt also für offene, eindeutige Buchstabenformen und ausreichend Abstand zwischen Zeichen.</p>
<p>Beispiele für bekannte humanistische Serifenlose Schriften sind: Calibri, Verdana, Lucida Sans, Open Sans oder Source Sans Pro.</p>
<p>Andere bekannte serifenlose Schriftarten wie Arial oder Helvetica gelten als schwerer lesbar, da sie engere Innenräume der Buchstaben haben, die dadurch nicht so gut unterschieden werden können.</p>
<img src="../barrierefreie-textgestaltung-uie/image4.png" style="" alt="Gegenüberstellung eines Buchstabens C mit offener Zeichenform in Calibri und geschlossener Zeichenform in Arial." />
<p>Bei zu kleiner Schriftgröße, schlechter Sicht, zu geringem Kontrast oder ungünstigen Lichtverhältnissen, sieht da ein c mal schnell aus wie ein e. Außerdem gelten Schriftarten als schwerer lesbar, die außergewöhnlich dünne oder unübliche Merkmale aufweisen, die die Wiedererkennung ihrer Buchstabenformen reduzieren. Insbesondere bei geringerem Farbkontrast.</p>
<p>Ausführliche Infos zu Schriftarten findet ihr bei leserlich.info: <a href="https://leserlich.info/zeichen/schriftart">Schriftart</a></p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-schriftgröße">Schriftgröße</h4>
<p>Schriftgrößen je nach Endgerät der Nutzenden. Die Schriftart auf einem Smartphone, das näher vor die Augen gehalten wird, muss nicht so groß sein, wie bei Text auf einem Desktop. Die responsive Anpassung der Schriftarten ist also zu bedenken. Aus dieser Logik ergeben sich folgende Mindestgrößen (laut DIN 1450):</p>
<ul>
<li><p>Desktop / PC-Bildschirm: 34px für Überschriften, 22px für Textblöcke, 17px für nebensächlichen Text (z. B. Fußnoten)</p></li>
<li><p>Tablet: 27px für Überschriften, 18px für Textblöcke, 14px für nebensächlichen Text</p></li>
<li><p>Smartphone: 22px für Überschriften, 14px für Textblöcke, 11px für nebensächlichen Text</p></li>
</ul>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-zeilenabstand-und-zeichenabstand">Zeilenabstand und Zeichenabstand</h4>
<p>Der Zeilenabstand (der Abstand von Zeile zu Zeile) innerhalb eines Fließtexts sollte mindestens 1,5-mal so groß sein wie die Schriftgröße, damit sich Buchstaben in verschiedenen Zeilen nicht berühren. Bei langen Zeilen ist ein größerer Zeilenabstand sinnvoll, um den Rücksprung mit dem Auge zum nächsten Zeilenanfang zu erleichtern, während bei kurzen Zeilen ein etwas geringerer Abstand genügt. Für die Bildschirmdarstellung wird generell ein größerer Zeilenabstand empfohlen, der an Leseabstand und Zeilenlänge angepasst werden sollte; auf Smartphones mit kurzen Zeilen kann er hingegen verringert werden.</p>
<p>Hinweise zum Zeichenabstand (dem Abstand von Buchstaben und Zeichen innerhalb eines Wortes zueinander): Die in der Schriftart eingerichteten Zeichenabstände sollten niemals verringert werden. Wird Serifenschrift verwendet, dann sollten sich die Serifen nicht berühren, sodass die Buchstaben klar voneinander getrennt sind. Im Dark Mode oder bei hellem Text auf dunklem Hintergrund ist es empfehlenswert den Zeichenabstand um 2% zu erhöhen.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-zeilenlänge">Zeilenlänge</h4>
<p>Sehr lange Zeilen wirken weniger einladend und erschweren es den Lesenden, nach dem Zeilenende wieder zum Anfang der nächsten Zeile zurückzufinden. Sehr kurze Zeilen hingegen führen zu häufigen Zeilenumbrüchen und erhöhen die Zahl der Worttrennungen. Daher empfiehlt es sich zum Beispiel für Fließtext höchstens 80 Zeichen (inklusive Leerzeichen) zu verwenden.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-sonderzeichen">Sonderzeichen</h4>
<p>Sonderzeichen müssen anhand ihrer Bedeutung gekennzeichnet werden. Sie dürfen nur verwendet werden, wenn sie von der Assistenztechnologie dem Kontext entsprechend korrekt ausgegeben werden können. In der Praxis kann man zwischen folgenden Funktionen von Sonderzeichen unterscheiden:</p>
<img src="../barrierefreie-textgestaltung-uie/image5.png" style="" alt="Darstellung eines Buttons mit der Beschriftung ‚Weiter‘ und zwei Größerzeichen als Pfeil, zur Veranschaulichung eines dekorativen Symbols " />
<p>Dekorative Sonderzeichen: Sonderzeichen, die keinen Inhalt vermitteln, sind als dekorativ auszuzeichnen, sodass sie von Assistenztechnologien ignoriert werden. Beispiel: Ein Button mit der Beschriftung „Weiter »“. Die beiden Größerzeichen sind rein dekorativ und sollten daher nicht von der Assistenztechnologie ausgegeben werden. Die programmatische Beschriftung für diesen Schalter sollte also lediglich „Weiter“ lauten.</p>
<img src="../barrierefreie-textgestaltung-uie/image6.png" style="" alt="Dialogfenster mit angedeutetem Textinhalt und Schaltfläche ‚Schließen‘ in der rechten oberen Ecke, dargestellt als X-Symbol." />
<p>Zweckentfremdete inhaltstragende Sonderzeichen, die nicht ihrer Bedeutung entsprechend verwendet werden, sind mit einem aussagekräftigen Alternativtext zu versehen. Beispiel: Button mit der Beschriftung x. Das Multiplikationszeichen vermittelt visuell die Information „Schließen“. Damit Assistenztechnologien die Funktion des Buttons korrekt ausgeben, sollte der Button mit „Schließen“ alternativ beschriftet werden (ggf. mit einem Hinweis, was geschlossen wird, z. B. „Fenster schließen“). Das Sternchen (<code>\*</code>) gilt bei Verwendung als <a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/pflichtfeldkennzeichnung.html">Pflichtfeldkennzeichnung</a> nicht als zweckentfremdet.</p>
<p>Zweckbezogene inhaltstragende Sonderzeichen, die entsprechend ihrer Bedeutung verwendet werden, können genutzt werden, sofern das Zeichen durch Assistenztechnologien korrekt ausgegeben wird. Andernfalls soll es mit einem aussagekräftigen Alternativtext versehen werden.</p>
<p>Ein Beispiel für inhaltstragende Sonderzeichen ist eine mathematische Formel „3+5 > 5-3“: Die beiden Rechenzeichen sowie das Größerzeichen werden von der Assistenztechnologie korrekt ausgegeben und können somit verwendet werden.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-großschreibung">Großschreibung</h4>
<p>Die Groß- und Kleinschreibung soll gemäß der Rechtschreibregeln verwendet werden, anstatt beispielsweise ganze Textabschnitte in Großbuchstaben zu gestalten. Da sich Großbuchstaben weniger voneinander unterscheiden, verringert das die Lesbarkeit.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-textanordnung-und-silbentrennung">Textanordnung und Silbentrennung</h4>
<p>Linksbündiger Text (Flattersatz) verhindert im Gegensatz zum Blocksatz unregelmäßige Wortabstände oder häufige Silbentrennung und ist daher lesbarer. Für die Silbentrennung muss ein Zeichen verwendet werden, welches von der Assistenztechnologie nicht ausgegeben wird. Zum Beispiel ein Bindestrich. Alternativ muss auf die Silbentrennung verzichtet werden.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-hervorhebungen-von-text-und-links">Hervorhebungen von Text und Links</h4>
<p>Hervorhebungen sollen sparsam verwendet werden. Eine klar strukturierte Gestaltung verbessert das Textverständnis. Dazu können Hervorhebungen in fettem oder eventuell farbigem Schriftbild (mit ausreichend starkem Farbkontrast) gehören. Zu viele Hervorhebungen wirken allerdings unruhig und erschweren die Orientierung, daher sollten sie sparsam eingesetzt werden. Außerdem gilt es zu beachten, dass Hervorhebungen dieser Art nicht von Screenreadern erfasst werden und daher nur der visuellen Textstrukturierung dienen sollten. Kursive Schriftschnitte oder Unterstreichungen verschlechtern die Lesbarkeit und sollten vermieden werden.</p>
<p>Eine Ausnahme der Unterstreichung sind Links, die im Webdesign üblich sind und als Markierung eines interaktiven Elements dienen. Links sollten beim Hovern mit der Maus oder Auswählen mit der Tastatur deutlich erkennbar reagieren, also durch mehr als nur einen reinen Farbwechsel.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-farben-und-kontrast">Farben und Kontrast</h4>
<p>Alle Textinhalte müssen zum Hintergrund einen Farbkontrast von mindestens 4,5:1 haben. Bei großer Schrift (ab 24px bzw. ab 18,7px bei fettem Schriftschnitt) ist ein Kontrastverhältnis von mindestens 3:1 ausreichend. Wenn über die Verwendung unterschiedlicher Schriftfarben eine Information übermittelt wird, dann muss der Kontrastabstand zwischen den Farben jeweils mindestens 3:1 betragen. Dies gilt, wenn die Farben an sich keine Bedeutung besitzen, sondern nur der Farbunterschied zwischen den Farben relevant ist.</p>
<img src="../barrierefreie-textgestaltung-uie/image7.png" style="" alt="Vertikales Navigationsmenü; der Menüpunkt ‚Glossar‘ ist farblich hervorgehoben und als aktiv gekennzeichnet." />
Ein Beispiel ist ein aktiver Menüpunkt einer Webseitennavigation: Die Hintergrundfarbe des ausgewählten Menüpunkts muss sich von der Hintergrundfarbe aller anderen Menüunkte um mindestens 3:1 unterscheiden. Unterscheidet sich die Farbe einer Hervorhebung nicht mit mindestens 3:1 vom umgebenden Text, sollte die Information zusätzlich textlich oder anderweitig eindeutig gekennzeichnet werden, damit sie auch ohne Wahrnehmung des Farbunterschieds verständlich bleibt.
<p>Wenn über die Verwendung einer Farbe eine Information vermittelt wird und die Farbe an sich eine Bedeutung besitzt, muss die Information zusätzlich auf andere Weise gekennzeichnet werden. Zum Beispiel zeigt „grün“ eine korrekte und „rot“ eine falsche Eingabe in einem Formular an. Hier reicht die farbliche Kennzeichnung nicht aus und muss textlich oder anderweitig ergänzt werden.</p>
<h4 id="barrierefreie-textgestaltung-in-user-interface-elementen-individuelle-nutzungspräferenzen">Individuelle Nutzungspräferenzen</h4>
<p>Eine Software oder Website muss die vom Nutzenden individuell gewählten Schrift‑ und Farbeinstellungen des Betriebssystems oder Browsers übernehmen können. Wird dies nicht unterstützt, muss das in der Erklärung zur Barrierefreiheit beschrieben sein. Zusätzlich kann die Anwendung eigene Einstellungsoptionen für Schrift und Farben anbieten. Vorgaben zu Farbkontrasten gelten nur, solange Nutzende die Farben nicht selbst ändern.</p>
<p>Für Textpassagen sollen folgende Anpassungen möglich sein:</p>
<ul>
<li><p>Vorder‑ und Hintergrundfarbe unabhängig vom restlichen Design ändern</p></li>
<li><p>Zeilenlänge auf 80 Zeichen begrenzen</p></li>
<li><p>Blocksatz deaktivieren</p></li>
<li><p>Zeilenabstand auf 150 % erhöhen</p></li>
<li><p>Absatzabstand auf das 1,5‑Fache des Zeilenabstands vergrößern</p></li>
<li><p>Die Kontrastanforderungen gelten auch hier nur, wenn die Farben nicht individuell angepasst wurden.</p></li>
</ul>
<h3 id="barrierefreie-textgestaltung-in-user-interface-elementen-weiterführende-links">Weiterführende Links</h3>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/schrift.html">Schrift - Barrierefreie Gestaltung von User Interface-Elementen</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/farben_und_kontraste.html#praxistipp-farbkodierung">Praxistipp Farbkodierung</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/bfit-leitfaeden/redaktion/kontraste.html">Kontraste für eine barrierefreie Gestaltung</a></p></li>
<li><p><a href="https://leserlich.info/">Leserlich.info</a></p></li>
<li><p><a href="https://leserlich.info/schriftgroessenrechner">Schriftgrößenrechner (leserlich.info)</a></p></li>
</ul>
<h3 id="barrierefreie-textgestaltung-in-user-interface-elementen-checkliste">Checkliste</h3>
<ol>
<li><p><strong>Schriftarten</strong>: Am besten sind Schriften aus der Familie der humanistischen Serifenlosen zu lesen (z.B. Calibri, Lucida Sans, Verdana), da sie offene, gut voneinander unterscheidbare Buchstaben haben.</p></li>
<li><p><strong>Schriftgröße</strong>: Die ideale Mindestschriftgröße für Textblöcke ist am Desktop 22px, am Tablet 18px und am Smartphone 14px. Für andere Medien kann das der Schriftgrößenrechner von leserlich.info bestimmen.</p></li>
<li><p><strong>Zeilenabstand</strong>: Zeilenabstand im Fließtext mindestens 1,5-mal der Schriftgröße. Bei sehr kurzen Zeilen (z. B. am Smartphone) kann etwas geringerer Abstand verwendet werden.</p></li>
<li><p><strong>Zeilenlänge</strong>: Für Fließtext maximal 80 Zeichen inklusive Leerzeichen pro Zeile.</p></li>
<li><p><strong>Sonderzeichen</strong>: Dekorative Zeichen als „dekorativ“ auszeichnen (werden vom Screenreader nicht vorgelesen). Zweckentfremdete Zeichen mit Alternativtext versehen (z. B. „Schließen“ für „x“). Bedeutungsgemäß genutzte Sonderzeichen (z.B. + oder -) sind in Ordnung, sofern korrekt auslesbar.</p></li>
<li><p><strong>Großschreibung</strong>: Groß- und Kleinschreibung nach Rechtschreibregeln nutzen. Keine längeren Passagen komplett in GROSSBUCHSTABEN verfassen, da dies die Lesbarkeit reduziert.</p></li>
<li><p><strong>Textanordnung & Silbentrennung</strong>: Linksbündigen Flattersatz verwenden (bessere Lesbarkeit als Blocksatz). Silbentrennung nur bei Assistenztechnologie-kompatiblem Trennzeichen (z. B. Bindestrich). Alternativ: Silbentrennung ganz vermeiden.</p></li>
<li><p><strong>Hervorhebungen von Text und Links</strong>: Hervorhebungen sparsam einsetzen (fett/farbig mit ausreichendem Kontrast). Keine Kursivschrift oder Unterstreichungen als Hervorhebung nutzen. Unterstreichung nur für Links. Links müssen beim Hover/Focus visuelles Feedback geben (mehr als Farbwechsel).</p></li>
<li><p><strong>Farben & Kontrast</strong>: Kontrastverhältnis von Text zum Hintergrund mindestens 4,5:1, bei großer oder fetter Schrift mindestens 3:1. Werden Informationen durch Farbunterschiede vermittelt, Kontrast zwischen den verwendeten Farben mindestens 3:1. Liegt Farbunterschied darunter oder hat eine Farbe definierte Bedeutung (z. B. Rot für Fehler, Grün für korrekt), Information zusätzlich textlich oder auf andere Weise eindeutig kennzeichnen.</p></li>
<li><p><strong>Flexible Nutzungspräferenzen</strong>: Eine Software oder Website muss, die vom Nutzenden individuell gewählten Schrift‑ und Farbeinstellungen des Betriebssystems oder Browsers übernehmen können.</p></li>
</ol>
<h2 id="barrierefreie-videos">Barrierefreie Videos</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/barrierefreievideos.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_barrierefreie_videos.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="..//barrierefreie-videos/image2.png" style="" alt="" />
<h3 id="barrierefreie-videos-einleitung">Einleitung</h3>
<p>Barrierefreie Videos sind so gestaltet, dass alle Menschen unabhängig von Beeinträchtigungen oder technischen Einschränkungen die Inhalte vollumfänglich wahrnehmen können. Dies kommt insbesondere Menschen mit Seh- oder Hörbeeinträchtigungen zugute, nützt aber auch vielen anderen. Beispielsweise profitieren auch Nicht-Muttersprachler oder Nutzende ohne Kopfhörer von Untertiteln und Transkripten.</p>
<p>Ein barrierefreies Video kombiniert verschiedene Zugänglichkeits-Komponenten: Untertitel für hörbare Inhalte, Audiodeskription für visuelle Inhalte, Übersetzung in Deutscher Gebärdensprache (hier nicht enthalten, bitte schaut euch dafür den BFIT-Leitfaden <a href="/bfit-leitfaeden/5.0/grundlagen/gebaerdensprachvideos-nach-bitv.html#" data-pdf-page="gebärdensprachevideos-nach-bitv-20" data-pdf-anchor="" data-pdf-level="2">Gebärdensprachevideos nach BITV 2.0</a> an), sowie zugängliche Player-Steuerung und ergänzende Transkripte. All diese Aspekte sollten idealerweise von Beginn an mitgeplant werden, um aufwendige Nachbesserungen zu vermeiden. Im Folgenden geben wir einen praxisorientierten Leitfaden, der klare Handlungsanweisungen und technische Hinweise enthält. Verstehen, welche Barrieren noch bestehen und wie sie Unterstützung erhalten können.</p>
<h3 id="barrierefreie-videos-rechtliche-grundlagen">Rechtliche Grundlagen</h3>
<p>Die Pflicht zur Gestaltung barrierefreier Videos beruht auf einem mehrstufigen Rechtsrahmen. Auf europäischer Ebene gilt die EU-Webseitenrichtlinie 2016/2102. Sie wurde in Deutschland durch das Behindertengleichstellungsgesetz (BGG) umgesetzt. Es verpflichtet öffentliche Stellen des Bundes dazu, ihre Websites und Apps – einschließlich Videos – barrierefrei zu gestalten. Diese Anforderungen werden durch die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) konkretisiert.</p>
<p>Die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) macht dazu konkrete Vorgaben. Diese werden als erfüllt vermutet, wenn digitale Inhalte den Anforderungen harmonisierten, europäischen Standards EN 301 549 (Version 3.2.1) entsprechen. Dieser Standard bezieht sich wiederum auf die Erfolgskriterien der WCAG (Web Content Accessibility Guidelines) in der Version 2.1 der Konformitätsstufen A und AA.</p>
<h3 id="barrierefreie-videos-wcag-erfolgskriterien-für-videos">WCAG-Erfolgskriterien für Videos:</h3>
<p>Nach WCAG 2.1/2.2 müssen Videos je nach Inhalt bestimmte Erfolgskriterien erfüllen (für Konformitätslevel A oder AA):</p>
<ul>
<li><p><strong>Untertitel für aufgezeichnete Medien</strong> (WCAG-Erfolgskriterium 1.2.2, Stufe A): Für alle vorab produzierten Videos mit Ton müssen Untertitel bereitstehen.</p></li>
<li><p><strong>Audiodeskription oder Text-Alternative für Videos</strong> (1.2.3, Stufe A): Visuelle Informationen in Videos müssen zumindest in Textform oder alternativ als Audiodeskription verfügbar sein.</p></li>
<li><p><strong>Untertitel für Live-Medien</strong> (1.2.4, Stufe AA): Live-Übertragungen mit Ton sollen ebenfalls untertitelt werden (sofern zumutbar).</p></li>
<li><p><strong>Audiodeskription für aufgezeichnete Videos</strong> (1.2.5, Stufe AA): Wichtige visuelle Inhalte in aufgezeichneten Videos müssen mittels Audio beschrieben werden (durch eine zusätzliche Tonspur oder integrierte Bildbeschreibungen).</p></li>
</ul>
<h3 id="barrierefreie-videos-untertitel-closed-open--live-captions">Untertitel (Closed, Open & Live Captions)</h3>
<h4 id="barrierefreie-videos-was-sind-untertitel">Was sind Untertitel?</h4>
<p>Untertitel sind schriftliche Textzeilen, die den gesprochenen Ton eines Videos wiedergeben und sichtbar eingeblendet werden. Diese enthalten nicht nur Dialoge, sondern auch wichtige Geräusche, Musik und andere Audiohinweise (z. B. „[Telefon klingelt]“ oder „[dramatische Musik]“), soweit sie zum Verständnis relevant sind.</p>
<p>Man unterscheidet:</p>
<ul>
<li><p><strong>Closed Captions (CC)</strong>: Abschaltbare Untertitel, die individuell ein- oder ausgeblendet werden können (z. B. über ein CC-Symbol im Player)</p></li>
<li><p><strong>Open Captions</strong>: Permanent ins Video eingebrannte Untertitel, die nicht deaktivierbar sind. Open Captions müssen besonders gut lesbar gestaltet sein, da Nutzer sie nicht anpassen können.</p></li>
<li><p><strong>Live-Untertitel</strong>: Untertitel für Live-Übertragungen (z. B. bei Webcasts, Online-Events oder Fernsehlivestreams). Sie werden in Echtzeit erstellt, entweder durch menschlich erstellte Schriftdolmetschenung oder automatisiert via Spracherkennung. Live-Untertitel haben naturgemäß eine gewisse Verzögerung und können Fehler enthalten; dennoch sind sie für gehörlose Zuschauer bei Live-Events sehr wichtig.</p></li>
</ul>
<h4 id="barrierefreie-videos-anforderungen-an-barrierefreie-untertitel">Anforderungen an barrierefreie Untertitel:</h4>
<p>Untertitel machen audiovisuelle Inhalte für Menschen mit Hörbehinderung zugänglich und nützen auch vielen anderen Nutzenden. Damit Untertitel effektiv und zugänglich sind, sollten folgende Punkte beachtet werden:</p>
<ul>
<li><p><strong>Vollständigkeit</strong>: Alle gesprochenen Inhalte und wichtigen Audio-Informationen müssen im Text erscheinen. Dazu gehören Dialoge, Off-Kommentare sowie Geräusche oder Musik, sofern sie für Handlung oder Stimmung wesentlich sind.</p></li>
<li><p><strong>Synchronität</strong>: Untertitel müssen lippensynchron zum gesprochenen Wort eingeblendet werden. Eine Person, die das Video ohne Ton schaut, soll das Gefühl haben, nahezu zeitgleich mitzulesen, was gesagt wird.</p></li>
<li><p><strong>Eindeutigkeit</strong>: Es soll immer klar erkennbar sein, wer spricht. Wenn verschiedene Personen sprechen, kann dies etwa durch vorangestellte Namenslabels („Max: …“) oder unterschiedliche Farben/Positionen der Untertitel kenntlich gemacht werden. Farbige Sprecherzuordnung wird z. B. von tauben Nutzenden geschätzt, ist aber mit Augenmaß einzusetzen (hoher Kontrast erforderlich!).</p></li>
<li><p><strong>Lesbarkeit</strong>: Untertitel sollten in gut lesbarer Schriftart und -größe erscheinen, idealerweise ohne Serifen und mit ausreichendem Kontrast zum Hintergrund. Gängig ist weiße oder gelbe Schrift auf schwarzem halbtransparentem Balken, da dies auf verschiedenem Videohintergrund gut sichtbar bleibt. Es dürfen maximal zwei Zeilen gleichzeitig erschienen, um das Sichtfeld nicht zu überfrachten. Die Zeilenlänge sollte begrenzt sein – im deutschen Fernsehen sind z. B. ca. 37 Zeichen pro Zeile üblich.</p></li>
<li><p><strong>Anzeigedauer</strong>: Jede Untertitel-Einblendung muss lang genug stehen, damit durchschnittliche Leser sie erfassen können. Als grobe Richtlinie gilt: keine Einblendung kürzer als ~1,5 Sekunden; lieber länger bei komplexen Sätzen. Im Zweifel sollte man das Video testweise mit Untertiteln anschauen und prüfen, ob komfortabel mitgelesen werden kann.</p></li>
<li><p><strong>Platzierung</strong>: Untertitel dürfen keine wichtigen Bildelemente verdecken. In der Regel stehen sie am unteren Bildschirmrand. Falls dort etwa Einblendungen (z. B. Bauchbinden mit Namen) vorkommen, platziert man die Untertitel höher oder teilt den Screen, damit sowohl Text als auch Video-Inhalt sichtbar bleiben. Manche Player erlauben es Nutzenden auch, die Untertitel-Position anzupassen.</p></li>
</ul>
<h4 id="barrierefreie-videos-erstellung-und-technische-umsetzung">Erstellung und technische Umsetzung:</h4>
<p>Mittlerweile gibt es zahlreiche Tools, um Untertitel zu erstellen. Drei gängige Vorgehensweisen sind:</p>
<ol>
<li><p>Manuelle Untertitelung erstellen: Mit spezialisierten Programmen kann das Video geladen, Textpassagen eingetippt und genau zeitkodiert werden. Dies liefert oft die beste Qualität, erfordert aber Aufwand und Übung.</p></li>
<li><p>Automatische Spracherkennung nutzen: Es gibt Plattformen und Programme die automatische Untertitelung anbieten. Diese sollte man allerdings korrigieren und nachbearbeiten, da Erkennungsfehler (v.a. bei Eigennamen, Fachbegriffen oder Dialekten) häufig sind. Solche Tools transkribieren das Video und erzeugen u.a. Untertiteldateien (z. B. SRT oder VTT), die man anschließend einbinden kann.</p></li>
<li><p>Extern untertiteln lassen: Für wichtige Inhalte (z. B. Imagefilme, Lehrvideos) kann man Dienstleister beauftragen. Diese liefern meist professionelle Qualität und auch Untertitel nach Standardformat. Üblich sind .SRT-Dateien (SubRip) oder WebVTT (.vtt), die sowohl Zeitstempel als auch Text enthalten. Vorteil: diese Dateien sind klein und können getrennt vom Video bereitgestellt werden (Closed Captions).</p></li>
</ol>
<p>Beim Upload auf Video-Plattformen sollte man immer prüfen, wie Untertitel unterstützt werden. YouTube z. B. ermöglicht das Hochladen eigener Untertitel oder die direkte Online-Bearbeitung im Video-Manager. LinkedIn, Facebook, Twitter (X) und viele andere akzeptieren ebenfalls SRT-Dateien zum Video. Informiert euch über die Vorgaben der Plattform (Formate, Dateibenennung etc.) und testet nach dem Upload, ob die Captions korrekt angezeigt werden.</p>
<h4 id="barrierefreie-videos-besonderheiten-bei-live-untertiteln">Besonderheiten bei Live-Untertiteln:</h4>
<p>Live-Untertitelung erfordert spezielle Software oder Dienstleister. Es gibt Lösungen mit Spracherkennung (etwa Zoom oder Teams bieten automatische Echtzeit-Untertitel an), jedoch sind diese nicht immer ausreichend genau. Für professionelle Ansprüche sollte ein Live-Untertitel-Dienst (Schriftdolmetschung) eingebunden werden, der via Stream untertitelt. Stellte vor dem Event sicher, dass der Player/Streamingdienst Live-Untertitel unterstützt und das Publikum weiß, wie sie aktiviert werden. Wenn Live-Untertitel technisch nicht machbar sind, sollten zumindest im Nachgang eine Aufzeichnung mit Untertiteln bereitgestellt oder ein Transkript des Gesagten veröffentlicht werden.</p>
<p>Weitere Infromationen zu Untertiteln könnt ihr hier lesen: <a href="/bfit-leitfaeden/5.0/redaktion/untertitel.html#" data-pdf-page="untertitel-für-barrierefreie-inhalte" data-pdf-anchor="" data-pdf-level="2">Untertitel für barrierefreie Inhalte</a></p>
<h3 id="barrierefreie-videos-audiodeskription">Audiodeskription</h3>
<h4 id="barrierefreie-videos-was-ist-audiodeskription-ad">Was ist Audiodeskription (AD)?</h4>
<p>Audiodeskription ist die hörbare Beschreibung wichtiger visueller Elemente eines Videos für Menschen, die es nicht sehen können. Ein Sprecher oder eine Sprecherin vermittelt dabei zwischen Dialogen die Informationen, die man sonst nur visuell erhielte – z. B. das Aussehen von Personen, Gestik/Mimik, Handlungen ohne Dialog, Szenenwechsel, eingeblendeter Text oder Grafiken. Audiodeskriptionen sind insbesondere für blinde und sehbehinderte Menschen essentiell, damit sie dem Video inhaltlich folgen können. Aber auch sehende Nutzende in bestimmten Situationen (z. B. jemand, der ein Video nebenbei „nur hört“) profitieren vom zusätzlichen Bildkommentar.</p>
<h4 id="barrierefreie-videos-formen-der-audiodeskription">Formen der Audiodeskription:</h4>
<ul>
<li><p><strong>Eingebaute Audiodeskription</strong>: Hier wird die Beschreibung direkt im regulären Video-Audio untergebracht – entweder indem vorhandene Sprechpausen genutzt werden (zwischen den Dialogen), oder indem man die Moderation so gestaltet, dass visuelle Inhalte gleich mitbeschrieben werden. Beispielsweise könnte ein Erklärvideo so beschrieben werden: „Auf dem Schaubild sehen wir drei Balken – der größte ist blau und repräsentiert 50%..“ statt nur „Hier sehen wir die Statistik“. Diese integrative Methode entspricht dem „Zwei-Sinne-Prinzip“: Informationen werden nach Möglichkeit immer zugleich auditiv und visuell bereitgestellt. Ist die AD (Audiodeskription) von vornherein ins Skript integriert, spricht man auch von „integrativer Audiodeskription“, die sehr effizient und nutzerfreundlich ist.</p></li>
<li><p><strong>Zusätzliche Audiodeskriptionsspur</strong>: Hier wird eine separate Audiospur produziert, auf der eine Sprecherstimme nur die Beschreibungen liefert, während der Originalton des Videos leiser im Hintergrund läuft. Dies wird oft als alternative Version des Videos bereitgestellt („Videoversion mit Audiodeskription“) oder – falls der Player dies unterstützt – als umschaltbare Tonspur angeboten. Vorteil: Die Originalfassung bleibt unverändert, und die AD-Version kann nachträglich produziert werden. Nachteil ist, dass man zwei Dateien verwalten muss und Nutzende aktiv die AD-Version wählen müssen.</p></li>
<li><p><strong>Erweiterte Audiodeskription</strong>: Wenn ein Video sehr wenige oder gar keine Pausen für Beschreibungen lässt (z. B. actionreiche Szenen mit Dauer-Dialog), kann eine erweiterte AD nötig sein. Dabei wird das Video temporär angehalten, um längere Beschreibungen einzufügen, und läuft danach weiter. Dieses Verfahren wird in WCAG als AAA-Erfolgskriterium (1.2.7) geführt und vor allem bei Filmproduktionen eingesetzt, wo vollständige Barrierefreiheit erreicht werden soll. In Web-Videos ist es eher selten, da das Einfrieren der Handlung für alle Zuschauenden merklich ist. Ein pragmatischer Ansatz im Web-Kontext kann stattdessen sein, zusätzlich eine ausführliche Inhaltsbeschreibung in Textform bereitzustellen (siehe Transkripte), falls die Audio-Beschreibung nicht alles abdecken kann.</p></li>
</ul>
<h4 id="barrierefreie-videos-wann-ist-eine-ad-audiodeskription-erforderlich">Wann ist eine AD (Audiodeskription) erforderlich?</h4>
<p>Immer dann, wenn rein visuelle Informationen für das Verständnis wichtig sind und nicht bereits durch den normalen Ton vermittelt werden. Beispiele: Ein Video zeigt Texttafeln oder Folien ohne vorzulesen – hier braucht es AD, die den Text vorliest. Oder es läuft eine Handlung ohne Dialog, die später wichtig ist – auch das sollte beschrieben werden. Es ist hingegen keine AD nötig, wenn ein Video überwiegend aus einer sprechenden Person besteht (z. B. Vortrag vor neutralem Hintergrund) und keine weiteren visuellen Inhalte vermittelt. In solchen Fällen wäre eine Audiodeskription redundant. Die WCAG erlauben bei vorab aufgezeichneten Videos auf Level A entweder eine AD oder alternativ ein vollständiges Text-Transkript. Für Stufe AA wird jedoch ausdrücklich eine Audiodeskriptions-Tonspur verlangt (Erfolgskriterium 1.2.5), es sei denn, das Video ist ohnehin bereits „selbstbeschreibend“ gestaltet (Zwei-Sinne-Prinzip). In der Praxis sollte man also spätestens bei komplexeren Videos abwägen: Kann eine blinde Person nur anhand des Originaltons dem Geschehen folgen? Wenn nein, muss eine AD her.</p>
<h4 id="barrierefreie-videos-erstellung-einer-audiodeskription">Erstellung einer Audiodeskription:</h4>
<p>Die Produktion einer guten Audiodeskription ist anspruchsvoll, da sie sowohl sprachlich präzise als auch künstlerisch stimmig sein soll. Größere Organisationen oder öffentliche Stellen beauftragen hierfür oft professionelle Hörfilm-Autoren, die auf AD spezialisiert sind. Es gibt in Deutschland Standards und eingespielte Techniken, u.a. die Beachtung von Reihenfolgen (zuerst Personen, dann Handlungen, dann Umgebung beschreiben), die Nutzung von Präsens und prägnanten Formulierungen, etc. Für kleinere Projekte kann man AD aber auch in Eigenregie erstellen.</p>
<h5 id="barrierefreie-videos-tipps">Tipps</h5>
<ul>
<li><p><strong>Skript schreiben</strong>: Schaut das Video und notiert euch in chronologischer Reihenfolge die visuell wichtigen Punkte, die nicht im Originalton vorkommen. Formuliert kurze, klare Sätze in Gegenwartsform. Beispiel: Statt „Er hatte einen Brief in der Hand, den er las.“ besser „Er liest einen Brief.“</p></li>
<li><p><strong>Zeitfenster nutzen</strong>: Platziert die beschriebenen Sätze so, dass sie in natürliche Pausen oder Lücken im Originalton fallen. Achtet darauf, Dialoge nicht zu überlagern. Wenn nötige Beschreibungen nicht in die vorhandenen Pausen passen, überlegt, ob einige weniger wichtige Elemente weggelassen werden können oder ob ggf. doch eine erweiterte AD/alternative Lösung nötig ist.</p></li>
<li><p><strong>Vertonung</strong>: Lasst das AD-Skript von einer gut verständlichen Stimme einsprechen. Ideal sind professionelle Sprecher uns Sprecherinnen mit klarer Aussprache. Die Aufnahme muss technisch sauber sein (kein Rauschen, Lautstärke ähnlich zum Originalton). Falls ihr selbst sprecht: übt das Timing mit dem Video, sprecht ruhig und deutlich.</p></li>
<li><p><strong>Mischen</strong>: Beim Zusammenführen mit dem Originalvideo (z. B. in einem Schnittprogramm) wird die AD-Spur so abgemischt, dass die Originalgeräusche leicht gedimmt werden, wenn die Erklärung spricht – aber niemals ganz stumm, damit Atmosphäre erhalten bleibt. Sobald kein AD mehr zu hören ist, Originalton wieder normal anheben.</p></li>
</ul>
<p>Hat man die AD-Version produziert, stellt sich die Frage der Bereitstellung: Wie bieten wir die Audiodeskription an? Optimal ist eine umschaltbare Audiodeskription im Player, sodass Nutzende per Knopfdruck eine AD an- und ausschalten können. Einige barrierefreie Videoplayer unterstützen dies. In HTML5-Video lässt sich eine zweite Tonspur einbetten, jedoch ist die Browser-Unterstützung für Audio-Track-Wechsel begrenzt (Stand 2025). Alternativ kann man das Video mit AD als separate Datei bereitstellen – etwa durch einen zweiten Video-Player unter dem Hauptvideo, mit Hinweis „Video mit Audiodeskription“. Wichtig: Beide Versionen synchron halten und gleich auffindbar machen. Eine blinde Person sollte ohne große Mühe direkt zur AD-Version gelangen können (z. B. via Link oder Schalter, der per Screenreader erreichbar ist).</p>
<h3 id="barrierefreie-videos-barrierefreie-transkripte">Barrierefreie Transkripte</h3>
<p>Ein Transkript ist eine Textfassung des Video-Inhalts. Im einfachsten Fall ist es der Wortlaut aller gesprochenen Dialoge (ähnlich einem Untertitel-Skript). Ein beschreibendes Transkript geht einen Schritt weiter und enthält zusätzlich schriftliche Beschreibungen der visuellen Ereignisse im Video– also quasi das, was in einer Audiodeskription vorkäme, nur in Textform. Transkripte sind ein wichtiges Hilfsmittel, um Videoinhalte auch ohne das Medium selbst zugänglich zu machen.</p>
<p>Davon profitieren:</p>
<ul>
<li><p>gehörlose und schwerhörige Menschen, die lange Texte evtl. einfacher lesen können als schnelle Untertitel (da man sich Zeit lassen kann).</p></li>
<li><p>blinde und sehbehinderte Menschen. Ein Braille-Transkript ermöglicht taubblinden Personen den Zugang zu Videos, den weder Audio noch Untertitel allein gewährleisten könnten. Für diese kleine Gruppe ist ein vollständiges Text-Transkript oft der einzige Zugang zu Multimediainhalten.</p></li>
<li><p>alle Nutzenden, die Inhalte durchsuchen oder offline nachlesen wollen. Transkripte bieten eine schnelle Möglichkeit, inhaltlich zu recherchieren, Zitate zu kopieren oder ein Video in Ruhe zu studieren, ohne es abspielen zu müssen. Zudem verbessern Transkripte die Auffindbarkeit (SEO) von Videos, da Suchmaschinen den Text indexieren können.</p></li>
</ul>
<h4 id="barrierefreie-videos-anforderungen">Anforderungen</h4>
<p>Ein gutes Transkript soll alle wesentlichen Inhalte des Videos wiedergeben. Das umfasst: den gesprochenen Text (möglichst wortgetreu oder zumindest sinngemäß), Kennzeichnung verschiedener sprechender Personen(z. B. mit Namen oder Initialen) und Beschreibung relevanter Aktionen. Beispielsweise könnte ein Transkriptausschnitt so aussehen:</p>
<pre tabindex="0"><code>Max: Herzlich willkommen zu unserem Schulungsvideo.
[Blendet eine Folie mit dem Titel "Agenda" ein\]
Max: Zuerst schauen wir uns die Grundlagen an.
</code></pre><p>Hier wird deutlich, wer spricht und was visuell passiert (Einblenden einer Folie). Wichtig ist, dass ein Leser des Transkripts sich das Video ohne Bild und Ton vollständig vorstellen kann. Ein beschreibendes Transkript kann also Audiodeskription ersetzen, wenn es detailliert, genug ist. Allerdings ersetzt ein Transkript nicht die Untertitel für gehörlose während des Videoabspielens, da es asynchron zum Video ist. Es dient eher als ergänzendes Angebot „zum Nachlesen“.</p>
<h4 id="barrierefreie-videos-erstellung-von-transkripten">Erstellung von Transkripten:</h4>
<p>Wenn ihr bereits Untertitel und ggf. ein Audiodeskriptionsskript erstellt habt, könnt ihr diese Quellen nutzen, um ein Transkript zusammenzustellen. Häufig reicht es, die Untertiteltexte aneinanderzureihen (für den Dialog-Teil) und dort, wo Audiodeskriptionen vorhanden sind, eine kurze Beschreibung einzufügen. Achtet darauf, dass die chronologische Reihenfolge stimmt und verseht das Transkript idealerweise mit Zeitmarken oder Abschnittstiteln, falls es sehr lang ist. Falls nicht ohnehin vorhanden, fügt Sprecher-Namen hinzu, damit der Kontext klar bleibt.</p>
<h4 id="barrierefreie-videos-bereitstellung">Bereitstellung:</h4>
<p>Transkripte sollten in einem einfachen, barrierefreien Format angeboten werden – am besten als HTML-Text direkt auf der Webseite oder als gut zugängliches PDF/Word-Dokument. Ein HTML-Transkript hat den Vorteil, dass es direkt im Browser gelesen, per Screenreader vorgelesen und per STRG+F durchsucht werden kann. Manche Videoplayer bieten eine eingebaute Transkript-Anzeige, die sogar synchron mit dem Video mitläuft. Solche Lösungen sind ideal, da Nutzende selbst entscheiden können, ob sie das Transkript parallel zum Video sehen möchten.</p>
<p>Stellt das Transkript in der Nähe des Videos bereit, z. B. als Link „Transkript herunterladen“ oder klappbarer Textbereich unter dem Video („Transkript anzeigen“). Weist ggf. darauf hin, welche Version es beschreibt („Transkript der Video-Version mit Audiodeskription vom 01.01.2025“ – so ist klar, auf welchen Schnitt es sich bezieht).</p>
<h4 id="barrierefreie-videos-automatisierung">Automatisierung:</h4>
<p>Es gibt Tools, die aus Videos automatisch Transkripte erzeugen (Spracherkennung). Diese ähneln den automatischen Untertiteln und müssen ebenso nachbearbeitet werden. In vielen Fällen hat man aber das Skript (bei eigenen Produktionen) ohnehin schriftlich vorliegen, sodass das Transkript mit wenig Aufwand erstellt werden kann.</p>
<h3 id="barrierefreie-videos-kontraste-schriftgrößen-und-visuelle-gestaltung">Kontraste, Schriftgrößen und visuelle Gestaltung</h3>
<p>Die visuelle Gestaltung eines Videos beeinflusst maßgeblich, wie gut verschiedene Nutzergruppen die Inhalte erkennen können. Hier geht es sowohl um das Video selbst (z. B. Text in Folien, Farben, Kameraführung) als auch um ergänzende Einblendungen wie Untertitel, Gebärdenfenster etc. Einige Leitlinien für barrierefreie Gestaltung:</p>
<ul>
<li><p><strong>Ausreichende Kontraste</strong>: Stellt sicher, dass alle wichtigen visuellen Informationen mit hohem Farbkontrast dargestellt werden. WCAG fordert für Text einen Kontrast von mindestens 4,5:1 (bzw. 3:1 für große Schrift). Beispielsweise sollten sich Schriftzüge auf Folien oder Grafiken deutlich vom Hintergrund abheben. Verwendet bei Text am besten dunkle Schrift auf hellem Hintergrund oder umgekehrt. Auch bei Diagrammen und Grafiken: Unterschiedliche Kurven nicht nur durch Farbe unterscheiden, sondern z. B. auch durch Muster oder Label. Farbkombinationen, die häufige Seheinschränkungen betreffen (Rot-Grün, Blau-Lila, Grün-Braun), sollten vermieden oder zusätzlich markiert werden. Nutzt gegebenenfalls ein Kontrast-Checker-Tool, um die Farbwerte zu prüfen.</p></li>
<li><p><strong>Lesbare Schriftgrößen</strong>: Alle Textelemente im Video (z. B. Folientexte, eingeblendete Namen, Untertitel) sollten groß genug sein, um auch von sehbehinderten Nutzenden erkannt zu werden. Bedenket, dass Videos oft auf kleinen Bildschirmen gesehen werden. Eine Mindestschriftgröße von ~18–24 pt (für Vollbild auf einem PC) ist ratsam; auf Folien in Präsentationsvideos lieber noch größer. Sans-Serif-Schriftarten sind meist besser lesbar auf Bildschirmen. Vermeidet verschnörkelte Fonts oder durchgehende Großschreibung von längeren Texten.</p></li>
<li><p><strong>Blinken und Flackern vermeiden</strong>: Schnelle Blinkeffekte oder flackernde Lichter können für Menschen mit Epilepsie gefährlich sein. Auch Laufschriften (Ticker) oder ständig wechselnde Einblendungen sind für viele schwer erfassbar. Verzichtet auf unnötige Animationen im Bildhintergrund. Wenn Bewegungen gezeigt werden, die nichts mit dem Inhalt zu tun haben, kann das ablenken – besser weglassen. Einblende-Effekte für Text sollten schlicht sein (z. B. simples Erscheinen statt hektischem Hereinfliegen).</p></li>
<li><p><strong>Einblendungen (Visual Overlays)</strong>: Viele Videos nutzen Texteinblendungen wie Namensbänder, Titel, Kapitelüberschriften etc. Gestaltet diese nach den gleichen Prinzipien: klare Schrift, große Größe, hoher Kontrast, genügend Anzeigedauer. Platziert die Einblendungen so, dass sie nicht mit bereits vorhandenen Untertiteln kollidieren. Falls euer Video sowohl Untertitel als auch Namenseinblendungen hat, kann man z. B. die Namensschilder oben links positionieren statt unten, um nicht an derselben Stelle wie Untertitel zu erscheinen.</p></li>
</ul>
<p>Zusammengefasst: Eine gute visuelle Gestaltung stellt sicher, dass wesentliche Inhalte gut sichtbar und leicht erfassbar sind.</p>
<h3 id="barrierefreie-videos-checkliste-zur-umsetzung-von-barrierefreien-videos">Checkliste zur Umsetzung von Barrierefreien Videos</h3>
<h4 id="barrierefreie-videos-checkliste-untertitel">Checkliste: Untertitel</h4>
<ul>
<li><p><strong>Untertitelspur vorhanden</strong>: Für alle gesprochenen Passagen und relevanten Geräusche liegt eine Untertitelung vor (Datei oder eingebrannt).</p></li>
<li><p><strong>Qualität geprüft</strong>: Keine gravierenden Tipp- oder Synchronisationsfehler; Untertitel laufen im Timing mit der Sprache mit.</p></li>
<li><p><strong>Lesbarkeit sichergestellt</strong>: Ausreichende Schriftgröße, hoher Kontrast, max. 2 Zeilen, sinnvolle Zeilenumbrüche (ca. 30–40 Zeichen pro Zeile).</p></li>
<li><p><strong>Inhalt vollständig</strong>: Wichtige Audio-Infos (Musik, Geräusche, Sprecherwechsel) sind im Text angegeben (ggf. in eckigen Klammern oder kursiv).</p></li>
<li><p><strong>Position optimiert</strong>: Untertitel verdecken keine wichtigen Inhalte im Video (ggf. alternative Position oder Hintergrundbox genutzt).</p></li>
<li><p><strong>Plattform-Test</strong>: Untertitel auf der Zielplattform (Webseite, Social Media) lassen sich ein- und ausblenden und funktionieren in verschiedenen Browsern sowie auf mobilen Geräten.</p></li>
</ul>
<h4 id="barrierefreie-videos-checkliste-audiodeskription">Checkliste: Audiodeskription</h4>
<ul>
<li><p><strong>Relevanz geprüft</strong>: Das Video wurde darauf analysiert, ob visuelle Informationen enthalten sind, die ein nichtsehender Mensch nicht aus dem Originalton erfährt.</p></li>
<li><p><strong>AD-Inhalt vollständig</strong>: Die Audiodeskription deckt alle inhaltlich wesentlichen visuellen Elemente ab (Personen, Aktionen, eingeblendeter Text, Grafiken, Schauplatzwechsel etc.). Unwesentliches wurde weggelassen, um die Beschreibung effizient zu halten.</p></li>
<li><p><strong>Sprache und Länge</strong>: Die gesprochenen Beschreibungen sind kurz, präzise und verständlich formuliert. Die Sprecherstimme ist klar und gut hörbar. AD-Passagen wurden optimal in Pausen platziert, ohne wichtige O-Ton-Information zu überdecken.</p></li>
<li><p><strong>Technische Umsetzung</strong>: Die AD-Spur ist sauber abgemischt (Originalton hörbar, aber bei AD-Passagen leicht abgesenkt). Die Bereitstellung erfolgt benutzerfreundlich – z. B. als zweite Tonspur im Player oder als alternativ abrufbares Video. Anleitung/Hinweis zur Aktivierung der AD ist vorhanden.</p></li>
<li><p><strong>Qualitätssicherung</strong>: Nach Fertigstellung wurde die AD-Version idealerweise von einer sehbehinderten Person oder einem Experten getestet. Verständlichkeit, Timing und Vollständigkeit wurden bestätigt.</p></li>
</ul>
<h4 id="barrierefreie-videos-checkliste-transkript">Checkliste: Transkript</h4>
<ul>
<li><p><strong>Transkript vorhanden</strong>: Zu jedem längeren Video ist ein Text-Transkript als HTML oder Download verfügbar, das alle gesprochenen und visuell wichtigen Inhalte abbildet.</p></li>
<li><p><strong>Vollständigkeit</strong>: Das Transkript enthält neben dem Dialog auch Hinweise auf Geräusche/Musik sowie beschreibende Passagen für visuelle Ereignisse (mindestens in dem Umfang, wie es auch eine Audiodeskription täte).</p></li>
<li><p><strong>Struktur & Sprecher</strong>: Unterschiedliche Sprecherrollen sind kenntlich gemacht (Name oder Rolle vor der Äußerung). Das Dokument ist übersichtlich formatiert (Absätze, ggf. Zeitstempel oder Kapitelüberschriften).</p></li>
<li><p><strong>Zugriffsformat</strong>: Der Transkript Text ist in barrierefreiem Format bereitgestellt (HTML empfohlen). Falls als PDF/Dokument, wurde auf Tags und zugängliche Formatierung geachtet.</p></li>
<li><p><strong>Verknüpfung mit Video</strong>: Das Transkript ist leicht auffindbar in direktem Zusammenhang mit dem Video (z. B. unter dem Player oder via Schaltfläche „Transkript“). Es ist klar, zu welcher Videoversion es gehört und ggf. welcher Stand (falls Video aktualisiert wurde, Transkript ebenfalls aktualisiert).</p></li>
</ul>
<h4 id="barrierefreie-videos-checkliste-visuelle-gestaltung">Checkliste: Visuelle Gestaltung</h4>
<ul>
<li><p><strong>Kontrast geprüft</strong>: Alle Texte und wichtigen Bildelemente heben sich deutlich vom Hintergrund ab (Kontrast ≥4,5:1 für normalen Text). Keine Pastell-auf-Pastell Farbkombis für Kerninhalte.</p></li>
<li><p><strong>Text gut lesbar</strong>: Schriftarten ohne Schnörkel, ausreichend groß. Keine langen Textpassagen in Großbuchstaben. In Präsentationen/Dokumenten: minimale Schriftgröße eingehalten, Inhalte eventuell zusätzlich im Begleitmaterial vorhanden.</p></li>
<li><p><strong>Keine schnellen Effekte</strong>: Kein Flackern oder Blinken, das epileptische Anfälle auslösen könnte. Keine dauerlaufenden Newsticker, die nicht pausierbar sind. Bewegte Hintergründe vermieden, sofern sie nicht zum Inhalt gehören.</p></li>
<li><p><strong>Einblendungen & Overlay</strong>: Zusätzliche Texte (Namen, Titel) ausreichend groß und kontrastreich. Zeitlich so platziert, dass sie in Ruhe gelesen werden können. Einblendungen verdecken keine anderen relevanten Elemente (z. B. Untertitel, Dolmetscherfenster).</p></li>
<li><p><strong>Konsistentes Design</strong>: Das Video folgt einem einheitlichen Gestaltungskonzept. Wiederkehrende Elemente (Logo, Intro/Outro, Hintergrundmusik) sind konsistent, was Orientierung und Wiedererkennung fördert. Bei Serien: alle Videos haben vergleichbares Layout.</p></li>
<li><p><strong>Testdurchlauf</strong>: Video wurde hinsichtlich visueller Lesbarkeit getestet (z. B. auf kleinem Smartphone-Bildschirm abgespielt, um zu sehen, ob Text noch erkennbar ist). ggf. von Personen mit Sehbehinderung begutachten lassen.</p></li>
</ul>
<h3 id="barrierefreie-videos-weiterführende-informationen">Weiterführende Informationen:</h3>
<ul>
<li><p><a href="/bfit-leitfaeden/5.0/grundlagen/wcag-prinzip1.html#" data-pdf-page="wcag-prinzip-1-wahrnehmbarkeit" data-pdf-anchor="" data-pdf-level="2">WCAG: Prinzip 1 Wahrnehmbarkeit</a></p></li>
<li><p><a href="https://www.w3.org/WAI/WCAG21/Understanding/audio-description-prerecorded.html"><span lang="en">Understanding Success Criterion 1.2.5: Audio Description</span></a></p></li>
</ul>
<h2 id="kontraste-für-eine-barrierefreie-gestaltung">Kontraste für eine barrierefreie Gestaltung</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/kontraste.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_kontraste..pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../kontraste/image1.png" style="" alt="" />
<p>Die folgenden Erläuterungen stellen lediglich einen Überblick über das Thema Kontraste dar. Wir bieten Hinweise und Empfehlungen, die dabei helfen sollen, digitale Inhalte schnell und effektiv barrierefreier zu gestalten. Diese Tipps richten sich an alle, unabhängig von ihren Vorkenntnissen, und sollen praktische Werkzeuge zur Verbesserung der digitalen Barrierefreiheit bereitstellen. Wir erheben keinen Anspruch auf Vollständigkeit. Diese Hinweise dienen als Orientierungshilfe und sollen eine erste Einführung in das Thema bieten.</p>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-was-sind-kontraste">Was sind Kontraste?</h3>
<p>Kontraste beschreiben den Unterschied in Helligkeit oder Farbe zwischen zwei oder mehreren visuellen Elementen und ihrem Hintergrund. Im Fokus steht dabei, Texte, informationstragende Grafiken und grafische Bedienelemente bzw. deren Zustände klar wahrzunehmen und vom Hintergrund zu unterscheiden. Je höher der Kontrast, desto leichter lassen sich die Elemente voneinander abheben.</p>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-warum-sind-kontraste-wichtig-für-die-digitale-barrierefreiheit">Warum sind Kontraste wichtig für die digitale Barrierefreiheit?</h3>
<p>Die Einhaltung von Kontrastabständen ist ein wesentlicher Bestandteil der digitalen Barrierefreiheit, da sie die Wahrnehmbarkeit und Lesbarkeit von Inhalten verbessert. Dies ist besonders für Menschen mit eingeschränktem Sehvermögen, wie Sehschwächen, Farbenblindheit oder altersbedingten Beeinträchtigungen entscheidend. Menschen mit diesen Einschränkungen haben oft Schwierigkeiten, Inhalte mit geringer Helligkeits- oder Farbunterscheidung zu erkennen. Beispielsweise kann ein hellgrauer Text auf einem weißen Hintergrund für sie nahezu unsichtbar sein, während ein hoher Kontrast, wie schwarzer Text auf weißem Hintergrund, deutlich wahrgenommen wird.</p>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-welche-nutzergruppen-profitieren-davon">Welche Nutzergruppen profitieren davon?</h3>
<ul>
<li><p><strong>Menschen mit Sehbeeinträchtigungen</strong>: Personen mit eingeschränktem Sehvermögen benötigen starke Kontraste.</p></li>
<li><p><strong>Menschen mit Farbsehschwächen</strong>: Farbkombinationen wie Rot-Grün oder Blau-Gelb können von Personen mit Farbsehschwäche nicht deutlich unterschieden werden. Durch bewusste Farbwahl und Kontrastgestaltung wird die Zugänglichkeit für diese Nutzenden erhöht.</p></li>
<li><p><strong>Ältere Menschen</strong>: Mit zunehmendem Alter nimmt die Fähigkeit, Kontraste zu erkennen, ab. Ein kontrastreicheres Design sorgt für bessere Lesbarkeit und Wahrnehmbarkeit.</p></li>
<li><p><strong>Alle Menschen</strong>: Guter Kontrast hilft jedem, Inhalte klarer und schneller zu erfassen, was die allgemeine Nutzerfreundlichkeit steigert.</p></li>
</ul>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-relevante-wcag-erfolgskriterien">Relevante WCAG-Erfolgskriterien</h3>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-wcag-141----benutzung-von-farbe-minimum">WCAG 1.4.1 – Benutzung von Farbe (Minimum)</h4>
<p>Dieses Erfolgskriterium stellt sicher, dass Informationen nicht ausschließlich durch Farbe vermittelt werden. Das bedeutet, dass alle wichtigen Informationen auch ohne Farbwahrnehmung zugänglich sein müssen. Dies ist besonders wichtig für Menschen mit Farbenfehlsichtigkeit oder anderen Einschränkungen bei der Farbwahrnehmung. Weitere Informationen findet ihr auf der <a href="https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html">WCAG Seite zur Verwendung von Farbe.</a></p>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-wcag-143----kontrast-minimum">WCAG 1.4.3 – Kontrast (Minimum)</h4>
<p>Dieses Erfolgskriterium fordert einen Mindestkontrast von 4,5:1 für normalen Text (unter 24px bzw. ab 18,7px fettgedruckt) und 3:1 für große Schrift (ab 24px). Dies stellt sicher, dass Text und Hintergrund gut voneinander abgehoben sind, wodurch die Wahrnehmbarkeit erleichtert wird. Weitere Informationen findet ihr auf der <a href="https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum">WCAG Seite zu Mindestkontrasten</a></p>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-wcag-146----kontrastverstärkung">WCAG 1.4.6 – Kontrastverstärkung</h4>
<p>Für Nutzende mit stärkeren Sehbeeinträchtigungen empfiehlt die WCAG für großen Text und wesentliche grafische Inhalte ein Kontrastverhältnis von 7:1 (AAA-Erfolgskriterium). Dieses ist zwar nicht in der europäischen Norm (EN 301 549) gefordert, aber sinnvoll, besonders bei mobiler Nutzung in schlechten Lichtverhältnissen, z. B. in der Bahn oder im Bus. Dieser erhöhte Kontrastwert verbessert die Wahrnehmbarkeit und Nutzerfreundlichkeit besonders für ältere Menschen und Personen mit eingeschränkter Sehfähigkeit. Weitere Informationen dazu findet ihr unter <a href="https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced">Kontrastverstärkung in der WCAG</a></p>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-wcag-1411----nicht-text-kontrast">WCAG 1.4.11 – Nicht-Text-Kontrast</h4>
<p>Informationsgrafiken wie Diagramme sowie grafische Bedienelemente wie Buttons und Icons müssen einen Kontrast von mindestens 3:1 zu den direkt benachbarten Farben aufweisen, um für alle Nutzenden deutlich wahrnehmbar zu sein. Diese Vorgabe gilt nicht für Logos, Fotos, Screenshots, Flaggen etc. Details findet ihr in der <a href="https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast">WCAG Erklärung zu Nicht-Text-Kontrasten</a>.</p>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-praktische-umsetzung-der-wcag-erfolgskriterien">Praktische Umsetzung der WCAG-Erfolgskriterien</h3>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-informationen-nur-über-farbe-vermittelt-wcag--erfolgskriterium-141">Informationen nur über Farbe vermittelt (WCAG- Erfolgskriterium 1.4.1)</h4>
<h5 id="kontraste-für-eine-barrierefreie-gestaltung-beispiel-1-im-hauptmenü-einer-webseite-werden-die-aktuell-ausgewählten-menüeinträge-durch-eine-farbänderung-hervorgehoben">Beispiel 1: Im Hauptmenü einer Webseite werden die aktuell ausgewählten Menüeinträge durch eine Farbänderung hervorgehoben.</h5>
<figure>
<img src="../kontraste/image2.png" style="" alt="Menü mit farblich markierten Menüeintrag" />
<figcaption>Grafik 1: Hauptmenü mit einem aktivem Menüeintrag (blau gekennzeichnet)</figcaption>
</figure>
<p><strong>Umsetzung</strong>: Die ausgewählten Menüeinträge sollten entweder einen Kontrastabstand von mindestens 3:1 zu benachbarten Einträgen aufweisen oder zusätzlich durch weitere visuelle Merkmale wie Unterstreichung oder Umrandung hervorgehoben werden.<br>
Mit Kontrast-Tools lässt sich überprüfen, ob die gewählten Farbkombinationen die Kontrast-Anforderung erfüllen.</p>
<figure>
<img src="../kontraste/image3.png" style="" alt="Hauptmenü mit unterstrichenden Menüeintrag" />
<figcaption>Grafik 2: Hauptmenü mit einem aktiven Menüeintrag (rot und unterstrichen gekennzeichnet)</figcaption>
</figure>
<h5 id="kontraste-für-eine-barrierefreie-gestaltung-beispiel-2-in-einem-formular-wird-der-status-eines-feldes-mit-farben-dargestellt">Beispiel 2: In einem Formular wird der Status eines Feldes mit Farben dargestellt:</h5>
<ul>
<li><p>Grün für „gültig“.</p></li>
<li><p>Rot für „ungültig“.</p></li>
<li><p>Gelb für „unvollständig“.</p></li>
</ul>
<figure>
<img src="../kontraste/image4.png" style="" alt="Formular mit farblich unterschiedlichen Stati" />
<figcaption>Grafik 3: Formular mit farblich markierten Status in grün, rot und gelb</figcaption>
</figure>
<p><strong>Umsetzung</strong>: Es sollten Farbkombinationen gewählt werden, die für Menschen mit Farbsehschwächen gut unterscheidbar sind, wie z. B. Blau und Orange anstelle von Rot und Grün. Zusätzlich können Symbole wie ein Haken (✓), ein Kreuz (✕) oder ein Ausrufezeichen (!) verwendet werden, um die Statusanzeige auch unabhängig von Farben verständlich zu machen.<br>
Mit Tools wie einem Color Blindness Simulator lassen sich Farbpaletten auf ihre Zugänglichkeit prüfen und problematische Kombinationen vermeiden.</p>
<figure>
<img src="../kontraste/image5.png" style="" alt="Formular mit farblicher Unterscheidung und Symbolik" />
<figcaption>Grafik 4: Formular mit farblich markierten Status in blau, orange und gelb und einer dazugehörigen Symbolik</figcaption>
</figure>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-ausreichender-kontrast-zwischen-text-und-hintergrund-wcag--erfolgskriterium-143-und-146">Ausreichender Kontrast zwischen Text und Hintergrund (WCAG- Erfolgskriterium 1.4.3 und 1.4.6)</h4>
<h5 id="kontraste-für-eine-barrierefreie-gestaltung-beispiel-ein-abschnitt-einer-webseite-verwendet-hellgrauen-text-auf-einem-weißen-hintergrund">Beispiel: Ein Abschnitt einer Webseite verwendet hellgrauen Text auf einem weißen Hintergrund.</h5>
<figure>
<img src="../kontraste/Text_schwerz_zu_erkennen.png" style="" alt="Screenshot einer schwer zu lesbaren Grafik" />
<figcaption>Grafik 5: Hellgrauer Text auf weißem Hintergrund</figcaption>
</figure>
<p><strong>Umsetzung</strong>: Zur Erfüllung des WCAG-Erfolgskriterium 1.4.3 sollte der Mindestkontrast zwischen Text und Hintergrund 4,5:1 bei normaler Schrift (unter 24px bzw. ab 18,7px fettgedruckt) und bei größerer Schrift (ab 24px) 3:1 betragen.</p>
<p>Das WCAG-Erfolgskriterium 1.4.6 (erweiterter Kontrast, Level AAA) verlangt, dass der Kontrast zwischen Text und Hintergrund für normalen Text mindestens 7:1 beträgt und für großen Text mindestens 4,5:1.</p>
<p>Mit Kontrast-Checkern lässt sich sicherstellen, dass die gewählten Farbkombinationen diese Anforderung erfüllen.</p>
<figure>
<img src="../kontraste/test_ist_gut_lesbar.png" style="" alt="Screenshot einer gut zu lesbaren Grafik" />
<figcaption>Grafik 6: Schwarzer Text auf weißem Hintergrund</figcaption>
</figure>
<h4 id="kontraste-für-eine-barrierefreie-gestaltung-interaktive-elemente-deutlich-hervorheben-wcag-1411">Interaktive Elemente deutlich hervorheben (WCAG 1.4.11)</h4>
<p>####Beispiel: Interaktive grafische Bedienelemente wie ein Play-Button (z. B. ein weißes Dreieck auf schwarzem Hintergrund) oder Navigationspfeile für „Vor“ und „Zurück“ in einem Karussell.</p>
<figure>
<img src="../kontraste/image6.png" style="" alt="Bilderkarussel schlecht sichtbar" />
<figcaption>Grafik 7: Bilderkarussell mit Pfeilen in grauer Farbe auf weißem Hintergrund</figcaption>
</figure>
<p><strong>Umsetzung</strong>: Für eine gute Wahrnehmbarkeit müssen die Bedienelemente zu den benachbarten Farben ein Kontrastverhältnis von mindestens 3:1 aufweisen.<br>
Mit Kontrast-Tools lässt sich überprüfen, ob die gewählten Farbkombinationen diese Anforderung erfüllen.</p>
<figure>
<img src="../kontraste/image7.png" style="" alt ="Bilderkarussel gut sichtbar" />
<figcaption>Grafik 8: Bilderkarussell mit Pfeilen in weißer Farbe auf schwarzem </figcaption>
</figure>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-checkliste-zur-kontrastgestaltung">Checkliste zur Kontrastgestaltung</h3>
<ol>
<li><p>Informationen nur Farbe (WCAG-Erfolgskriterium 1.4.1)
</p><ul>
<li><p>Der Kontrast wichtiger Informationen ist mindestens 3:1 zur Farbe des benachbarten Elements</p></li>
<li><p>Wenn nicht, müssen die betreffenden Informationen (z. B. Links im Fließtext oder aktive Menüeinträge) durch zusätzliche visuelle Merkmale wie Unterstreichungen oder Umrandungen hervorgehoben werden.</p></li>
<li><p>Farben wurden gewählt, die auch für Menschen mit Farbsehschwäche gut unterscheidbar sind</p></li>
<li><p>Farbpaletten wurden auf ihre Zugänglichkeit überprüft und problematische Kombinationen vermieden</p></li>
<li><p>Prüfung via eines Contrast Checkers</p></li>
</ul>
</li>
<li><p>Kontrast zwischen Text und Hintergrund (WCAG-Erfolgskriterium 1.4.3)
</p><ul>
<li><p>Der Kontrast zwischen Text und Hintergrund erfüllt mindestens das Verhältnis 4,5:1 bei normaler Schrift (unter 24px bzw. ab 18,7px fettgedruckt) und bei größerer Schrift (ab 24px)</p></li>
<li><p>Prüfung via eines Contrast Checkers</p></li>
</ul>
</li>
<li><p>Kontrast zwischen Text und Hintergrund (WCAG-Erfolgskriterium 1.4.6 AAA)
</p><ul>
<li><p>Der Kontrast zwischen Text und Hintergrund erfüllt mindestens das Verhältnis 7:1 für normalen Text und 4,5:1 für große Schrift (mindestens 24px oder fettgedruckt in 18,7px)?</p></li>
<li><p>Prüfung via eines Contrast Checkers</p></li>
</ul>
</li>
<li><p>Interaktive Elemente hervorheben (WCAG-Erfolgskriterium 1.4.11)
</p><ul>
<li><p>Grafische Bedienelemente (z.B. Icons) haben einen ausreichend hohen Kontrast von mindestens 3:1 zu ihrem umliegenden Hintergrund</p></li>
<li><p>Der Rahmen eines Bedienelements, welches nur durch den Rahmen erkennbar ist, hat mindestens ein Kontrastverhältnis von 3:1 zum Hintergrund</p></li>
<li><p>Prüfung via eines Contrast Checkers</p></li>
</ul>
</li>
</ol>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-tools">Tools</h3>
<ul>
<li><p><a href="https://www.color-blindness.com/coblis-color-blindness-simulator/"><span lang="en">Coblis — Color Blindness Simulator – Colblindor</span></a></p></li>
<li><p><a href="https://webaim.org/resources/contrastchecker/">WebAIM: Contrast Checker</a></p></li>
<li><p><a href="https://www.tpgi.com/color-contrast-checker/"><span lang="en">Colour Contrast Analyser</span></a></p></li>
</ul>
<h3 id="kontraste-für-eine-barrierefreie-gestaltung-weitere-informationen">Weitere Informationen</h3>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/bgwa/">Handreichung zur barrierefreien Gestaltung von Webauftritten und Apps</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/">Handreichung zur Erstellung barrierefreier User Interface</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/accessible-uie/"><span lang="en">Reference book for creating accessible user interface elements</span></a></p></li>
<li><p><a href="https://www.w3.org/WAI/WCAG21/Understanding/distinguishable">WCAG Understanding Docs zu 1.4</a></p></li>
</ul>
<p>Die aufgeführten Tools und Informationen sind nicht als vollständig oder als die besten verfügbaren Lösungen zu verstehen. Sie dienen lediglich der ergänzenden Informationssammlung und sollen einen ersten Überblick über die verfügbaren Möglichkeiten bieten. Für eine umfassende Evaluierung empfehlen wir weiterführende Recherchen und den Vergleich mehrerer Optionen.</p>
<h2 id="leitfaden-für-barrierefreie-video-konferenzen">Leitfaden für barrierefreie Video-konferenzen</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/leifaden-barrierefreie-videokonferenzen.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/leifaden-barrierefreie-videokonferenzen.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../leitfaden-barrierefreie-videokonferenzen/image2.png" style="" alt="" />
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-warum-barrierefreie-videokonferenzen-wichtig-sind">Warum barrierefreie Videokonferenzen wichtig sind</h3>
<p>Videokonferenzen sind aus dem Arbeitsalltag nicht mehr wegzudenken. Sie ermöglichen ortsunabhängige Zusammenarbeit, Schulungen und Veranstaltungen.</p>
<p>Damit alle teilnehmen können, müssen Videokonferenzen barrierefrei geplant, durchgeführt und nachbereitet werden. Technische Funktionen (z.B. Untertitel oder Transkriptionen), allein reichen nicht aus. Entscheidend ist das Zusammenspiel aus Plattform, Einstellungen, Moderation und begleitenden Materialien.</p>
<p>Barrierefreie Videokonferenzen ermöglichen die gleichberechtigte Teilhabe aller Teilnehmenden.</p>
<p>Davon profitieren unteranderem:</p>
<ul>
<li><p><strong>Menschen mit Hörbeeinträchtigungen</strong>, die auf Untertitel oder Deutsche Gebärdensprache angewiesen sind.</p></li>
<li><p><strong>Blinde oder sehbehinderte Personen</strong>, die Screenreader nutzen.</p></li>
<li><p><strong>Personen mit motorischen Einschränkungen</strong>, die ausschließlich per Tastatur navigieren.</p></li>
<li><p><strong>Menschen mit kognitiven Einschränkungen</strong>, die auf klare Strukturen oder Leichte Sprache angewiesen sind.</p></li>
<li><p><strong>Alle Teilnehmenden in lauten Umgebungen oder mit instabiler Technik.</strong></p></li>
</ul>
<p>Barrierefreiheit ist kein Zusatz, sondern Voraussetzung für digitale Teilhabe.</p>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-rechtliche-und-normative-grundlage">Rechtliche und normative Grundlage:</h3>
<p>Die Pflicht zur Gestaltung barrierefreier Videokonferenzen beruht auf einem mehrstufigen Rechtsrahmen. Auf europäischer Ebene gilt die EU-Webseitenrichtlinie 2016/2102. Sie wurde in Deutschland durch das Behindertengleichstellungsgesetz (BGG) umgesetzt. Es verpflichtet öffentliche Stellen des Bundes dazu, ihre Websites, Apps elektronisch unterstützten Verwaltungsabläufe und deren grafische Benutzeroberflächen barrierefrei zu gestalten. Dazu gehören auch in diesem Rahmen durchgeführte Videokonferenzen. Diese Anforderungen werden durch die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) konkretisiert.</p>
<p>In der BITV 2.0 finden sich konkrete Vorgaben. Sie werden als erfüllt vermutet, wenn digitale Inhalte den Anforderungen des harmonisierten, europäischen Standards EN 301 549 entsprechen. Dieser Standard bezieht sich wiederum auf die Erfolgskriterien der WCAG (Web Content Accessibility Guidelines) der Konformitätsstufen A und AA.</p>
<p>Das vorliegende Dokument beruht auf den gesetzlichen Anforderungen des Bundes. In den einzelnen Bundesländern gelten eigene gesetzliche Bestimmungen. In einigen Fällen beziehen sich diese Regelungen auf das BGG und die BITV 2.0.</p>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-plattform--und-technik-anforderungen">Plattform- und Technik-Anforderungen</h3>
<p>Wenn die Plattform selbst nicht mit Tastatur oder Screenreader bedienbar ist oder Untertitel und Transkripte nicht ermöglicht, kann Moderation das nur begrenzt kompensieren.</p>
<p>Das World Wide Web Consortium (W3C) beschreibt die Plattformauswahl als zentralen Teil barrierefreier Remote-Meetings. Auch die EN 301 549 und andere Standards geben Aufschluss zu den Anforderungen zu Videokonferenzen. In diesem Dokument haben wir uns nur auf die WCAG konzentriert.</p>
<p>Die Plattform muss mindestens Folgendes erfüllen bzw. ermöglichen:</p>
<ul>
<li><p><strong>Tastaturbedienbarkeit</strong> ohne Fallen (WCAG 2.1.1/2.1.2).</p></li>
<li><p><strong>Sichtbarer Fokus</strong> (WCAG 2.4.7).</p></li>
<li><p><strong>Steuerelemente</strong> müssen für assistive Technologien programmatisch bestimmbar sein (WCAG 4.1.2 – Name/Rolle/Wert).</p></li>
<li><p><strong>Live-Untertitel</strong> müssen möglich sein (direkt im Tool oder via integrierbare Services), wenn Live-Audio stattfindet.</p></li>
<li><p><strong>Transkripte/Untertitel</strong> müssen nach dem Meeting bereitgestellt werden. (Download/Export oder Ablage in einem System, auf das Teilnehmende zugreifen können)</p></li>
</ul>
<p>Viele Plattformen sind „potenziell barrierefrei“, aber nur, wenn Admins/Hosts Funktionen (wie z. B. Untertitel) nicht deaktivieren, nicht einschränken und Teilnehmende wissen, wie sie Features einschalten.</p>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-vergleichstabelle-der-plattformen">Vergleichstabelle der Plattformen</h3>
<p>Hier werden Zoom, Microsoft Teams, Google Meet und WebEx gegenübergestellt. Der konkrete Funktionsumfang kann je nach Lizenzmodell, Betriebssystem, Version und individuellen Einstellungen deutlich variieren.</p>
<p>Es ist dringend zu empfehlen, jede Plattform im eigenen Nutzungsszenario zu testen. Prüft dabei insbesondere typische Kernabläufe z. B. wie Beitreten zum Meeting ohne Maus. Nur durch solche Praxis-Tests lässt sich zuverlässig beurteilen, ob eine Plattform für eure konkreten Anforderungen barrierefrei nutzbar ist.</p>
<p>Für die Übersichtstabelle haben wir die Videokonferenz-Plattformen anhand zentraler Barrierefreiheitsfunktionen untersucht Im Fokus standen vier Bereiche:</p>
<ul>
<li><p><strong>Tastatur und Screenreader</strong>: Es wurde geprüft, ob dokumentierte Tastenkombinationen vorhanden sind und ob integrierte Bedienungshilfen oder eine verlässliche Nutzung mit Screenreadern möglich ist.</p></li>
<li><p><strong>Untertitel</strong>: Untersucht wurde, ob Live-Untertitel aktiviert werden können und ob Einstellungen wie Sprache oder Anzeige konfigurierbar sind.</p></li>
<li><p><strong>Transkript und Export</strong>: Bewertet wurde, ob während oder nach dem Meeting Transkripte erstellt werden können und ob ein Export oder eine Weiterverarbeitung möglich ist.</p></li>
<li><p><strong>Dolmetsch- und Fixieroptionen</strong>: Hier wurde geprüft, ob Funktionen für Sprachdolmetschung vorhanden sind und ob Dolmetschende als eigenes Video-Fenster oder als Kachel dauerhaft fixiert, werden können.</p></li>
</ul>
<p>Die Übersicht basiert auf dem Stand von Februar 2026 und auf öffentlich verfügbaren Feature-Beschreibungen der Anbieter.</p>
<table>
<colgroup>
<col style="width: 30%" />
<col style="width: 20%" />
<col style="width: 20%" />
<col style="width: 20%" />
<col style="width: 20%" />
</colgroup>
<thead>
<tr>
<th>Plattform</th>
<th>Tastatur & Screenreader</th>
<th>Untertitel (live)</th>
<th><p>Transkript/Export</p></th>
<th>Dolmetsch-/Fixier-Optionen</th>
</tr>
</thead>
<tbody>
<tr>
<th>Zoom</th>
<td>Hotkeys/Shortcuts dokumentiert; Screenreader-Alerts konfigurierbar.</td>
<td>Manuelle & automatische Untertitel („Live-Transkription“) aktivier-/konfigurierbar</td>
<td>Audio-Transkription als VTT-Datei in Cloud-Aufzeichnungen; Untertitel als VTT speicherbar (Cloud)</td>
<td>„Gesprochene Sprache“ für bessere Caption-Qualität relevant; Übersetzte Untertitel konfigurierbar</td>
</tr>
<tr>
<th>Microsoft Teams</th>
<td>Umfangreiche Tastenkombinationen dokumentiert.</td>
<td>Liveuntertitel in Besprechungen verfügbar.</td>
<td>Live-Transkription sichtbar; Download als .docx oder .vtt</td>
<td>Sprachinterpretation/Dolmetsch-Einstellungen verfügbar.</td>
</tr>
<tr>
<th>Google Meet</th>
<td>Nutzung mit Screenreadern; integrierte Bedienungshilfen (Untertitel, Tastenkombinationen, Video anpinnen).</td>
<td>Übersetzte Untertitel inkl. Anpassung (Schriftart/-größe/Farbe/Hintergrund) und Wahl der gesprochenen Sprache.</td>
<td>Transkripte: nach Meeting per E‑Mail-Link.</td>
<td>„Kacheln koppeln“ kann, Vortragende Person+ Gebärdensprachdolmetschung zusammenhalten.</td>
</tr>
<tr>
<th>WebEx</th>
<td>Meetings werden für Kompatibilität mit JAWS getestet; Shortcuts funktionieren mit Screenreader.</td>
<td>Untertitel pro Nutzer aktivierbar; Speicherung nur bei Aufzeichnung Echtzeitübersetzung/-transkription möglich</td>
<td>Meetingabschriften/Transkripte über WebEx Assistant verwaltbar.</td>
<td>Pin/Focus für Videos – Hosts können eine Person (z. B. Dolmetscher) im Video-Fenster fixieren</td>
</tr>
</tbody>
</table>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-durchführung-moderation-kommunikation-und-inhalte">Durchführung, Moderation, Kommunikation und Inhalte</h3>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-zugang-onboarding-und-ankommen-ins-meeting">Zugang, Onboarding und „Ankommen ins Meeting“</h4>
<p>Viele Barrieren entstehen oft ganz am Anfang: Link/Client-Zwang, fehlende Einwahlnummer, unklare Rollen der Sprechenden, keine Supportkontakte. Das W3C empfiehlt ausdrücklich mehrere Verbindungswege (u. a. Telefon) und betont die Bedeutung einer guten organisatorischen Vorbereitung.</p>
<ul>
<li><p>Teilnehmende erhalten vorab eine zugängliche Anleitung zur Nutzung des Tools
</p><ul>
<li><p>Die Einladung enthält: Beitrittslink, Meeting-ID, Einwahldaten (wenn verfügbar), Info zu Untertiteln und Transkript, Info zum Melden von Barrieren, Supportkontakt, Agenda, Dateilinks (barrierefrei)</p></li>
</ul>
</li>
<li><p>Es gibt eine klar benannte Kontaktperson für technische Probleme vor und während des Termins.</p></li>
<li><p>Mindestens ein Chat ist vorhanden; alternativ zusätzlicher Kontaktkanal (Telefon oder Messenger), damit Probleme gemeldet werden können.</p></li>
<li><p>Wenn Untertitel und Transkription benötigt werden: die Aktivierung und Bedienung müssen in der Einladung erklärt werden, sonst bleibt die Funktion praktisch „unsichtbar“.</p></li>
</ul>
<h5 id="leitfaden-für-barrierefreie-video-konferenzen-hinweis">Hinweis</h5>
<p>Baut einen 10-minütigen „Ankommen“-Puffer mit ein: Technikcheck, Untertitel aktivieren, Audio prüfen Bei größeren Events hilft es, die Konferenz mit allen Funktionen vorab zu testen.</p>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-moderation-sprechdisziplin-chat-visuals">Moderation (Sprechdisziplin, Chat, Visuals)</h4>
<p>In Meetings findet Echtzeit-Kommunikation statt. Selbst wenn das Tool grundsätzlich zugänglich ist, scheitert Teilhabe, wenn die sprechende Person nicht identifizierbar ist, Visuals nicht beschrieben werden oder Chat-Fragen „stumm“ bleiben.</p>
<ul>
<li><p>Die sprechende Person wird immer namentlich angekündigt („Hier spricht …“). Das ist für Screenreader-Nutzende und bei Transkript-Auswertung essenziell.</p></li>
<li><p>Visuals (Slides, geteilte UIs, Whiteboards) werden verbal beschrieben; Präsentationsdateien werden nach Möglichkeit vorab barrierefrei versendet, weil geteilte Präsentationen für blinde Menschen oft nicht zugänglich sind.</p></li>
<li><p>Chat/Q&A: Inhalte im Chat werden regelmäßig vorgelesen/zusammengefasst, und Fragen werden in den Audio-Kanal überführt.</p></li>
<li><p>Bei Bedarf: Dolmetschung muss dauerhaft sichtbar und auffindbar sein (fixierbare Kachel / „Pin“ / „Anheften“).</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-anforderungen-an-präsentationen-und-geteilte-inhalte">Anforderungen an Präsentationen und geteilte Inhalte</h4>
<p>Präsentationen und geteilte Inhalte müssen visuell gut aufbereitet und für alle zugänglich sein. Selbst perfekte Untertitel helfen nicht, wenn die eigentliche Information ausschließlich visuell aufbereitet ist (wie Diagramme ohne Erklärung, Screenshots ohne Kontext). Außerdem sind unlesbare Folien (geringer Kontrast oder Schriftgröße) in Videokonferenzen noch problematischer als vor Ort, weil eine Skalierung oder Kompression der Inhalte dazukommt.</p>
<ul>
<li><p>Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein; die WCAG listet dafür u.a. Kontrast, Textskalierung, Struktur, Überschriften und Tastaturbedienbarkeit als relevante Kriterien auf.</p></li>
<li><p>Keine Informationsvermittlung nur über Farbe/Position („klick auf den grünen Button rechts“), sondern zusätzlich erklärender Text und gut strukturierte Darstellung der Inhalte.</p></li>
<li><p>Bei Bildern und Diagrammen: Textalternative im Material (z. B. im Handout) und mündliche Beschreibung in der Session.</p></li>
<li><p>Folien „Meeting-tauglich“: große Schrift, hohe Kontraste, klare Überschriften, kurze Aufzählungen, keine rein visuellen Pointer benutzen ohne verbale Ergänzung.</p></li>
</ul>
<h5 id="leitfaden-für-barrierefreie-video-konferenzen-hinweis-1">Hinweis</h5>
<p>Selbst bei zugänglicher Plattform Bildschirmfreigabe, können Inhalte oft nicht von Screenreadern verarbeitet werden; daher muss das Material als zugängliches Dokument verfügbar sein.</p>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-untertitelung-und-transkription">Untertitelung und Transkription</h3>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-live-untertitel-bereitstellen">Live-Untertitel bereitstellen</h4>
<p>Live-Untertitel sind für viele Menschen mit Höreinschränkungen der Schlüssel zur Teilhabe. Gleichzeitig sind automatische Verfahren fehleranfällig; bei Bedarf wird menschliche Korrektur oder Schriftdolmetschung empfohlen.</p>
<ul>
<li><p>Für Live-Audio in synchronisierten Medien müssen Untertitel bereitgestellt werden (WCAG-Erfolgskriterium 1.2.4).</p></li>
<li><p>In Informellen Meetings sind Auto-Captions (Untertitel), eine klare Sprechdisziplin und Korrektur, wenn eine Aufzeichnung veröffentlicht wird, notwendig.</p></li>
<li><p>In externen oder juristisch relevanten Meetings dürfen Auto-Captions nur als Zusatz verwendet werden. Primär: CART/Schriftdolmetschung oder ein professioneller Dienst (live). Im Anschluss sind eine Geprüfte Aufzeichnung mit korrigierten Untertiteln und ein Transkript bereitzustellen.</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-transkript--und-untertitel-dateiformate">Transkript- und Untertitel-Dateiformate</h4>
<p>Für Weitergabe, Archivierung und Nachbearbeitung braucht ihr portable Formate. Außerdem ist „Transkript“ nicht automatisch „Untertiteldatei“: Untertitel brauchen eine Zeitcodierung.</p>
<ul>
<li><p>Die Nachbereitung muss mindestens ein lesbares Texttranskript liefern: für kognitive Entlastung, Nachvollziehbarkeit und Dokumentation</p></li>
<li><p>Bei veröffentlichten Aufzeichnungen gibt es idealerweise zeitcodierte Untertitel</p></li>
<li><p>Praxis-Set von Formaten:
</p><ul>
<li><p>SubRip (.srt) als verbreitetes Einsteigerformat, von großen Plattformen unterstützt.</p></li>
<li><p>WebVTT (.vtt) als W3C-Spezifikation für Web-Texttracks, geeignet für Captions und Subtitles inkl. Zeitbezug.</p></li>
<li><p>TTML/IMSC für professionellere Workflows/Interchange</p></li>
</ul>
</li>
</ul>
<h5 id="leitfaden-für-barrierefreie-video-konferenzen-hinweis-2">Hinweis</h5>
<p>Automatische Untertitel können eine Videokonferenz zugänglicher machen, sind jedoch fehleranfällig. Spracherkennung erkennt Fachbegriffe, Namen oder mehrere gleichzeitig sprechende Personen häufig falsch. Auch schlechte Tonqualität verschlechtert die Ergebnisse deutlich. Automatische Untertitel eignen sich für interne Meetings oder informelle Veranstaltungen. Bei wichtigen Veranstaltungen, öffentlichen Terminen oder Schulungen sollten professionelle Live-Untertitel (z. B. durch Stenografen oder Untertitelnde) eingesetzt werden. Für Aufzeichnungen sollten automatisch erzeugte Untertitel immer nachbearbeitet und korrigiert werden. Automatische Untertitel sind daher eine hilfreiche Unterstützung, ersetzen aber keine qualitativ geprüften oder professionell erstellten Untertitel</p>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-häufige-barrieren">Häufige Barrieren</h3>
<ol>
<li><p><strong>„Auto-Untertitel reichen schon“</strong>: In wichtigen Kontexten stimmt das oft nicht. Plant menschliche Unterstützung oder mindestens eine Nachbearbeitung ein.</p></li>
<li><p><strong>Screenreader-Nutzende bekommen nur die Meldung „Bildschirm wird geteilt“</strong>: Das ist strukturell erwartbar; deshalb Materialien vorab oder parallel als zugängliche Dokumente bereitstellen und Visuals konsequent beschreiben.</p></li>
<li><p><strong>„Niemand weiß, wer spricht“</strong>: Untertitel und Transkripte werden schwer nutzbar; Menschen mit Sehbehinderung verlieren die Orientierung. Gegenmaßnahmen: Namensansage, Moderation, klare Reihenfolge der Beiträge.</p></li>
<li><p><strong>Policies sabotieren Barrierefreiheit</strong>: Wenn Admins Transkripte oder Untertitel deaktivieren (oder Downloadrechte unklar sind), scheitert die Nachbereitung. Gegenmaßnahmen: barrierefreie Standardrichtlinie/Template einrichten, Rollen & Zugriff vorab klären.</p></li>
</ol>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-weitere-informationen">Weitere Informationen:</h3>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/bfit-leitfaeden/redaktion/untertitel.html">Untertitel für barrierefreie Inhalte</a></p></li>
<li><p><a href="https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/Barrierefreie-Webkonferenzen/barrierefreie-webkonferenzen_node">Bundesfachstelle: Barrierefreie Webkonferenzen</a></p></li>
<li><p><a href="https://www.bfit-bund.de/DE/Publikation/meetingtool-vergleich?nn=69281d27401de22f3aa78921#doc69281d26401de22f3aa78848bodyText2">BFIT: Vergleich von Online-Meeting Plattformen</a></p></li>
</ul>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-zeitplan-für-die-vorbereitung-barrierefreier-videokonferenzen">Zeitplan für die Vorbereitung barrierefreier Videokonferenzen</h3>
<p>Der Zeitplan stellt eine Orientierung dar und ist nicht in jeder Organisation eins zu eins umsetzbar. Er soll vor allem einen ersten Eindruck vermitteln, wie eine strukturierte und barrierefreie Vorbereitung idealerweise ablaufen kann.</p>
<ul>
<li><p>Planung des Events
</p><ul>
<li><p>Bedarf erheben: Untertitel, DGS, Assistive Technologien abfragen</p></li>
<li><p>Geeignete Plattform auswählen und Barrierefreiheitsfunktionen prüfen</p></li>
</ul>
</li>
<li><p>T-10 Tage
</p><ul>
<li><p>Rollen festlegen: Host, Moderation, Chat-Betreuung, Untertitel-Verantwortliche</p></li>
<li><p>Interne Richtlinien und Datenschutz prüfen</p></li>
</ul>
</li>
<li><p>T-7 Tage
</p><ul>
<li><p>Präsentationen und Materialien barrierefrei erstellen</p></li>
<li><p>Materialien vorab versenden</p></li>
<li><p>Anleitung zur Nutzung der Plattform beilegen</p></li>
</ul>
</li>
<li><p>T-3 Tage
</p><ul>
<li><p>Technikprobe durchführen</p></li>
<li><p>Untertitel und Transkript testen</p></li>
<li><p>Screenreader- und Tastaturtest durchführen</p></li>
<li><p>Backup-Plan definieren</p></li>
</ul>
</li>
<li><p>T-0 Tag
</p><ul>
<li><p>Early Join ermöglichen</p></li>
<li><p>Soundcheck durchführen</p></li>
<li><p>Untertitel aktivieren</p></li>
</ul>
</li>
<li><p>T+7 14 Tage
</p><ul>
<li><p>Transkript und Untertitel exportieren</p></li>
<li><p>Inhalt redaktionell prüfen</p></li>
<li><p>Barrierefrei bereitstellen</p></li>
<li><p>Feedback auswerten</p></li>
</ul>
</li>
</ul>
<h3 id="leitfaden-für-barrierefreie-video-konferenzen-checkliste-für-eine-barrierefreie-videokonferenz">Checkliste für eine barrierefreie Videokonferenz</h3>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-einladung-und-zugang">Einladung und Zugang</h4>
<ul>
<li><p>Einladung und Zugang mit Screenreader und Maus testen</p></li>
<li><p>Einwahldaten für Telefon bereitstellen</p></li>
<li><p>Supportkontakt klar benennen</p></li>
<li><p>Sichtbarkeit des Fokus prüfen</p></li>
<li><p>Mute, Chat, Hand heben und weitere Funktionen ansagen lassen</p></li>
<li><p>Statusänderungen prüfen: Zustandsänderungen werden vermittelt</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-untertitel-aufzeichnung--transkription">Untertitel, Aufzeichnung & Transkription</h4>
<ul>
<li><p>In einem Testmeeting Untertitel einschalten: Untertitel sind sichtbar</p></li>
<li><p>Sprache korrekt einstellen</p></li>
<li><p>Transkript starten: Export testen</p></li>
<li><p>Probeaufzeichnung durchführen: Prüfen, ob Untertitel enthalten, sind</p></li>
<li><p>Speicherort und Zugriff testen</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-freigaben-und-materialien">Freigaben und Materialien</h4>
<ul>
<li><p>Bildschirmfreigabe testen</p></li>
<li><p>Parallel barrierefreies Dokument bereitstellen</p></li>
<li><p>Beschreibung visueller Inhalte üben</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-chat--und-qa-prozess">Chat- und Q&A-Prozess</h4>
<ul>
<li><p>Chat-Fragen eintippen lassen</p></li>
<li><p>Moderation liest Fragen laut vor</p></li>
<li><p>Wortmeldungsregeln klar kommunizieren</p></li>
</ul>
<h4 id="leitfaden-für-barrierefreie-video-konferenzen-hinweis-für-den-beschaffungsprozess">Hinweis für den Beschaffungsprozess:</h4>
<p>Legt in Ausschreibungen/Toolauswahl je nach Art der Videokonferenz Mindestfeatures fest z. B.: Untertitel (live), Transkript, Tastatur-Shortcuts, fixe Video-Kachel (für DGS-Dolmetschende), Chat-Moderation oder Aufzeichnung mit Untertiteln.</p>
<h2 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte">Sprachauszeichnung: Die richtige Sprache für barrierefreie Inhalte!</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/sprachauszeichnung.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_sprachauszeichnung.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../sprachauszeichnung/undraw_things-to-say_f5mi.png" style="" alt="" />
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-was-ist-eine-sprachauszeichnung">Was ist eine Sprachauszeichnung?</h3>
<p>Die Sprachauszeichnung kennzeichnet in digitalen Inhalten die Sprache, in der ein Text verfasst ist. Dies ist sowohl für komplette Webseiten, Dokumente als auch für einzelne Textabschnitte wichtig, um Technologien wie Screenreader die richtige Interpretation der Sprache zu ermöglichen.</p>
<p>Das <strong>WCAG-Erfolgskriterium 3.1.1</strong> verlangt, dass die Hauptsprache einer Webseite oder eines Dokuments korrekt festgelegt wird, damit Screenreader den Text richtig vorlesen können. Laut <strong>WCAG-Erfolgskriterium 3.1.2</strong> müssen Sprachwechsel klar gekennzeichnet werden, um Missverständnisse durch fehlerhafte Aussprache zu vermeiden.</p>
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-warum-ist-die-sprachauszeichnung-wichtig">Warum ist die Sprachauszeichnung wichtig?</h3>
<p>Die Sprachauszeichnung gewährleistet, dass digitale Inhalte für alle zugänglich sind, insbesondere für Menschen, die auf Vorlesefunktionen angewiesen sind. Die richtige Sprachauszeichnung ist in folgenden Fällen besonders entscheidend:</p>
<ul>
<li><p><strong>Richtige Aussprache</strong>: Wenn die Hauptsprache eines Dokuments oder einer Webseite nicht korrekt angegeben ist, kann der gesamte Inhalt in der falschen Sprache vorgelesen werden. Dies führt zu Missverständnissen und einer schlechten Nutzererfahrung für Nutzende</p></li>
<li><p><strong>Fehlende Erkennung von Sprachwechseln</strong>: Wenn Textabschnitte in einer anderen Sprache stehen, aber nicht korrekt markiert sind, wird der Text weiterhin in der Hauptsprache vorgelesen. Das führt zu fehlerhaften Aussprachen, die den Inhalt unverständlich machen. Ein typisches Beispiel wäre ein Zitat auf Englisch in einem deutschen Text – ohne Sprachauszeichnung würde das Zitat auf Englisch im deutschen Rhythmus und mit deutscher Aussprache vorgelesen, was es unverständlich macht.</p></li>
<li><p><strong>Mehrsprachige Inhalte zugänglich machen</strong>: Gerade in mehrsprachigen Dokumenten oder auf internationalen Webseiten ist die korrekte Kennzeichnung der Sprachen notwendig, um den Inhalt für verschiedene Nutzergruppen zugänglich zu halten.</p></li>
</ul>
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-wer-profitiert-davon">Wer profitiert davon?</h3>
<ul>
<li><p><strong>Menschen, die auf Vorlesefunktionen angewiesen sind</strong>: Diese Nutzergruppen sind auf die Sprachauszeichnung angewiesen, damit assistive Technologien Texte in der richtigen Aussprache und Grammatikstruktur vorlesen können.</p></li>
<li><p><strong>Internationale Zielgruppen</strong>: Mehrsprachige Inhalte werden für ein breites internationales Publikum zugänglich, wenn Sprachwechsel richtig markiert werden.</p></li>
<li><p><strong>Website-Betreiber</strong>: Bessere SEO-Leistungen werden erzielt, da Suchmaschinen die Inhalte in den korrekten Sprachen indexieren können.</p></li>
</ul>
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-wie-setzt-man-die-sprachauszeichnung-um">Wie setzt man die Sprachauszeichnung um?</h3>
<p>Die Sprachauszeichnung lässt sich sowohl in HTML für Webseiten als auch in Word- und PDF-Dokumenten leicht umsetzen.</p>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-umsetzung-auf-webseiten-html">Umsetzung auf Webseiten (HTML)</h4>
<p>In HTML kann die Hauptsprache der Webseite sowie Sprachwechsel in Abschnitten oder einzelnen Wörtern mit dem `lang`-Attribut festgelegt werden:</p>
<ul>
<li><p><strong>Hauptsprache einer Webseite</strong>: Füge das `lang`-Attribut zum `<html>`-Tag hinzu. Beispiel: <html lang="de">. Dies stellt sicher, dass die Seite als deutschsprachig erkannt wird.</p></li>
<li><p><strong>Sprache für einzelne Abschnitte oder Wörter ändern</strong>: Nutze das <code>lang</code>-Attribut, um Sprachwechsel zu kennzeichnen. Beispiel: <code><span lang="en">This is an English sentence.</span></code>. In diesem Fall wird nur der markierte Abschnitt in der englischen Sprache vorgelesen.</p></li>
</ul>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-umsetzung-in-microsoft-word-dokumenten">Umsetzung in Microsoft Word-Dokumenten</h4>
<p><strong>Hauptsprache festlegen</strong>:</p>
<ol>
<li><p>Öffne dein Word-Dokument.</p></li>
<li><p>Gehe im Menü zu Überprüfen > Sprache >Sprache> Sprache für Korrekturhilfen festlegen > Aktives Dokument</p></li>
<li><p>Wähle die gewünschte Hauptsprache aus.</p></li>
</ol>
<p><strong>Sprache für einzelne Abschnitte ändern</strong>:</p>
<ol>
<li><p>Markiere den Text, dessen Sprache du ändern möchtest.</p></li>
<li><p>Gehe erneut zu Überprüfen > Sprache >Sprache > Sprache für Korrekturhilfen festlegen.</p></li>
<li><p>Wähle die neue Sprache für diesen Abschnitt.</p></li>
</ol>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-umsetzung-in-adobe-acrobat-pro-dokumenten">Umsetzung in Adobe Acrobat Pro-Dokumenten</h4>
<p><strong>Hauptsprache festlegen</strong>:</p>
<ol>
<li><p>Öffne dein PDF in Adobe Acrobat Pro</p></li>
<li><p>Gehe zu Menü > Dokumenteigenschaften > Erweitert</p></li>
<li><p>Wähle unter Leseoptionen> Sprache die Hauptsprache deines Dokuments.</p></li>
</ol>
<p><strong>Sprache für einzelne Abschnitte ändern</strong>:</p>
<ol>
<li><p>Wähle in der Seitenleiste mit rechtsklick die Tags für Barrierefreiheit aus.</p></li>
<li><p>Gehe auf den Tag den du ändern möchtest</p></li>
<li><p>Klicke mit der rechten Maustaste auf den markierten Tag und wähle Eigenschaften.</p></li>
<li><p>Gehe in den Reiter Inhalt und ändere die Sprache.</p></li>
</ol>
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-checkliste">Checkliste</h3>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-hauptsprache-festlegen">Hauptsprache festlegen</h4>
<ul>
<li><p><strong>Webseite</strong>: Setze das `lang`-Attribut im `<html>`-Tag, z.B. `<html lang="de">`.</p></li>
<li><p><strong>Word</strong>: Wähle die Hauptsprache im Menü über Überprüfen > Sprache > Sprache für Korrekturhilfen festlegen.</p></li>
<li><p><strong>PDF</strong>: Wähle die Hauptsprache über Menü > Dokumenteigenschaften > Erweitert > Leseoptionen> Sprache.</p></li>
</ul>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-sprache-für-abschnitte-oder-wörter-ändern">Sprache für Abschnitte oder Wörter ändern</h4>
<ul>
<li><p><strong>Webseite</strong>: Verwende das `lang`-Attribut für bestimmte Abschnitte oder Wörter, z. B. `<span lang="en">`.</p></li>
<li><p><strong>Word</strong>: Markiere den Text und ändere die Sprache unter Überprüfen > Sprache > Sprache > Sprache für Korrekturhilfen festlegen.</p></li>
<li><p><strong>PDF</strong>: Markiere den Tag und ändere die Sprache in den Eigenschaften der Tags für die Barrierefreiheit.</p></li>
</ul>
<h4 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-prüfung">Prüfung</h4>
<ul>
<li><p>Teste deine Webseite oder dein Dokument mit einem Screenreader oder der Vorlesefunktionen von Browsern/Betriebssystem.</p></li>
<li><p>Überprüfe, ob die Sprachauszeichnung korrekt funktioniert und der Sprachwechsel erkannt wird.</p></li>
<li><p>Achte darauf das es nicht zu vielen Sprachwechseln kommt. Jedes einzelne fremdsprachige Wort sollte nicht markiert werden, diese reduzieren die Verständlichkeit.</p></li>
</ul>
<h3 id="sprachauszeichnung-die-richtige-sprache-für-barrierefreie-inhalte-hinweis">Hinweis:</h3>
<p>Die Sprachauszeichnungen wurden mit Microsoft Word 365 Version 2408 Build 16.0.17928.2011 und Adobe Acrobat Pro Version 2024.003.20112 getestet.</p>
<h2 id="strukturierung-von-textinhalten">Strukturierung von Textinhalten</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/strukturierung-von-textinhalten.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_strukturierung_von_textinhalten.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../strukturierung-von-textinhalten/image2.png" style="" alt="" />
<h3 id="strukturierung-von-textinhalten-warum-ist-die-strukturierung-von-textinhalten-wichtig">Warum ist die Strukturierung von Textinhalten wichtig?</h3>
<p>Eine klare und logische Strukturierung von Dokumenten und Webseiten ist ein zentraler Aspekt der digitalen Barrierefreiheit. Sie hilft nicht nur Menschen mit Beeinträchtigungen, den Inhalt zu verstehen und zu navigieren, sondern verbessert auch die Lesbarkeit und Zugänglichkeit für alle Nutzenden. Durch die Verwendung von Überschriften, Absätzen, Listen und Tabellen wird der Inhalt übersichtlich gegliedert, was eine einfache Navigation und ein besseres Leseverständnis ermöglicht.</p>
<h3 id="strukturierung-von-textinhalten-relevante-wcag-erfolgskriterien">Relevante WCAG-Erfolgskriterien</h3>
<h4 id="strukturierung-von-textinhalten-wcag-131----informationen-und-beziehungen">WCAG 1.3.1 – Informationen und Beziehungen</h4>
<p>Dieses Erfolgskriterium verlangt, dass die Struktur eines Dokuments oder einer Webseite durch semantische Auszeichnung (z. B. HTML-Tags) vermittelt wird. Screenreader und andere assistive Technologien können so die Beziehungen zwischen verschiedenen Teilen des Inhalts korrekt interpretieren.</p>
<h4 id="strukturierung-von-textinhalten-wcag-244----linkzweck-im-kontext-erkennbar">WCAG 2.4.4 – Linkzweck im Kontext erkennbar</h4>
<p>Der Zweck eines Links muss entweder durch den Linktext selbst oder im Kontext klar erkennbar sein. Screenreader und andere assistive Technologien ermöglichen es Nutzenden, effizient durch eine Webseite zu navigieren, indem sie von Link zu Link springen. Damit dies reibungslos funktioniert, muss der Linktext eindeutig den Zielinhalt oder die Funktion des Links beschreiben.</p>
<h4 id="strukturierung-von-textinhalten-wcag-246----überschriften-und-beschriftungen">WCAG 2.4.6 – Überschriften und Beschriftungen</h4>
<p>Überschriften und Beschriftungen müssen den Inhalt oder Zweck der Webseite und des Textes klar beschreiben. Eine logische Hierarchie der Überschriften (z. B. H1, H2, H3) ist hierbei wichtig, um eine verständliche Gliederung zu schaffen.</p>
<h3 id="strukturierung-von-textinhalten-wer-profitiert-davon">Wer profitiert davon?</h3>
<ul>
<li><p><strong>Menschen mit Sehbehinderungen oder Blindheit</strong>: Screenreader erkennen durch eine klare Struktur, wie Inhalte gegliedert sind, und ermöglichen es Nutzenden, effizient von Abschnitt zu Abschnitt zu springen.</p></li>
<li><p><strong>Menschen mit Lernschwierigkeiten</strong>: Eine gut strukturierte Seite oder ein gut strukturiertes Dokument erleichtern das Verstehen und Verarbeiten von Informationen.</p></li>
<li><p><strong>Menschen mit motorischen Einschränkungen</strong>: Durch eine klare Strukturierung wird die Navigation über Tastatur oder Screenreader vereinfacht, was den Zugang zu den Inhalten erleichtert.</p></li>
<li><p><strong>Allgemeine Nutzerfreundlichkeit</strong>: Auch Menschen ohne Beeinträchtigungen profitieren von einer gut strukturierten Webseite und gut strukturierten Dokumenten, da sie Informationen schneller finden und verarbeiten können.</p></li>
</ul>
<h3 id="strukturierung-von-textinhalten-so-strukturieren-sie-ihre-textinhalte-richtig">So strukturieren Sie Ihre Textinhalte richtig</h3>
<p>Die Struktur eines Textes sorgt dafür, dass Inhalte nicht nur visuell ansprechen sind, sondern auch von assistiven Technologien korrekt interpretiert werden können. Die Anpassungen der Struktur müssen programmatisch im Quellcode oder im Dokument in der Formatvorlage vorgenommen werden. Hier sind die wichtigsten Elemente zur Strukturierung von Inhalten.</p>
<h4 id="strukturierung-von-textinhalten-überschriftenhierarchie-h1---h6">Überschriftenhierarchie (H1 - H6)</h4>
<p>Jede Webseite oder jedes Dokument sollte <strong>eine</strong> Hauptüberschrift haben, die das Thema klar angibt. Weitere Inhalte sollten durch eine klare Hierarchie von Unterüberschriften gegliedert werden. Bei Dokumenten kann als Titel auch die entsprechende Formatvorlage gewählt werden. Sollte es für das Dokumentenformat kein Titel-Tag geben, kann auch eine H1 Überschrift mehrfach verwendet werden.</p>
<p>Hier ein Beispiel für eine Überschriftenhierarchie:</p>
<ul>
<li><p><strong>H1</strong>: Hauptkapitel oder Themenbereiche</p></li>
<li><p><strong>H2</strong>: Unterkapitel innerhalb eines Themenbereichs</p></li>
<li><p><strong>H3 - H6</strong>: Weitere detaillierte Unterpunkte</p></li>
</ul>
<p>Eine klare und logische Überschriftenhierarchie hilft nicht nur bei der Navigation mit Screenreadern, sondern verbessert auch die Suchmaschinenoptimierung (SEO). Überschriften dienen nur zu Organisation der Inhalte und sollten nicht aus visuellen Gründen genutzt werden.</p>
<h4 id="strukturierung-von-textinhalten-absätze-richtig-nutzen">Absätze richtig nutzen</h4>
<h5 id="strukturierung-von-textinhalten-kurze-und-prägnante-absätze">Kurze und prägnante Absätze</h5>
<p>Lange Textblöcke sollten vermieden werden. Teilen Sie den Text in kurze, thematisch zusammenhängende Absätze auf, um die Lesbarkeit zu erhöhen. Jeder Absatz sollte einen klaren Gedanken oder ein Thema enthalten.</p>
<h5 id="strukturierung-von-textinhalten-leere-zeilen-vermeiden">Leere Zeilen vermeiden</h5>
<p>Achten Sie darauf, dass Absätze und Zeilenumbrüche semantisch korrekt verwendet werden. Ein einfacher Zeilenumbruch<code>(<br>)</code>signalisiert keine inhaltliche Trennung, während ein neuer Absatz<code>(<p>)</code>deutlich macht, dass ein neues Thema oder ein neuer Gedanke beginnt.</p>
<h4 id="strukturierung-von-textinhalten-listen-und-aufzählungen">Listen und Aufzählungen</h4>
<p>Verwenden Sie Listen, um Informationen übersichtlich und leicht erfassbar zu präsentieren. Screenreader erkennen Listen und lesen sie strukturiert vor, was den Nutzenden hilft, den Inhalt besser zu verstehen.</p>
<ul>
<li><p><strong>Nummerierte Listen</strong><code>(<ol>)</code>sollten verwendet werden, wenn eine bestimmte Reihenfolge oder Priorität vorliegt.</p></li>
<li><p><strong>Ungeordnete Listen</strong><code>(<ul>)</code>sind für Aufzählungen ohne Reihenfolge sinnvoll.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-tabellen">Tabellen</h4>
<p>Tabellen sollten ausschließlich verwendet werden, um <strong>tabellarische Daten</strong> darzustellen – nicht für das Layout von Inhalten. Tabellen sollten klare Spalten- und Zeilenüberschriften haben, damit Screenreader sie korrekt interpretieren können.</p>
<ul>
<li><p>Überschriften für Spalten und Zeilen setzen</p></li>
<li><p>Vermeiden Sie verschachtelte Tabellen**, da sie schwer zugänglich und zu verstehen sind.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-verlinkungen">Verlinkungen</h4>
<p>Der Linktext sollte aussagekräftig sein, sodass Nutzende und assistive Technologien den Zweck des Links verstehen können. Vermeiden Sie Formulierungen wie „Klicken Sie hier“, sondern verwenden Sie stattdessen z. B. „Mehr erfahren über Barrierefreiheit“.
Siehe auch: <a href="/bfit-leitfaeden/5.0/redaktion/barrierefreielinks.html#" data-pdf-page="barrierefreie-links" data-pdf-anchor="" data-pdf-level="2">Barrierefreie Links</a></p>
<h4 id="strukturierung-von-textinhalten-textauszeichnung-z-b-fett-und-kursiv">Textauszeichnung (z. B. Fett und Kursiv)</h4>
<p>Verwenden Sie <strong>fett</strong> (<code><strong></code>) anstatt <code><b></code> und <strong>kursiv</strong> (<code><em></code>) sparsam und nur, wenn Sie Informationen hervorheben möchten. Dies hilft Nutzenden, wichtige Informationen leichter zu erkennen.</p>
<h3 id="strukturierung-von-textinhalten-detaillierte-umsetzung-strukturierung-in-html-und-microsoft-word">Detaillierte Umsetzung: Strukturierung in HTML und Microsoft Word</h3>
<h4 id="strukturierung-von-textinhalten-html">HTML</h4>
<h5 id="strukturierung-von-textinhalten-überschriftenstruktur-setzen">Überschriftenstruktur setzen:</h5>
<p>Verwenden Sie <code><h1></code> für die Hauptüberschrift, <code><h2></code> für wichtige Unterthemen und so weiter. Achten Sie darauf, keine Ebenen zu überspringen (z. B. nicht von <code><h1></code> direkt zu <code><h3></code> springen).</p>
<h6 id="strukturierung-von-textinhalten-beispiel">Beispiel</h6>
<pre tabindex="0"><code><h1>Hauptüberschrift</h1>
<h2>Unterüberschrift</h2>
<h3>Unterkapitel</h3>
</code></pre><h5 id="strukturierung-von-textinhalten-listen-strukturieren">Listen strukturieren:</h5>
<p>Verwenden Sie <code><ul></code> für <strong>ungeordnete</strong> Listen und <code><ol></code> für <strong>geordnete</strong> Listen.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-1">Beispiel:</h6>
<pre tabindex="0"><code><ul>
<li>Punkt 1</li>
<li>Punkt 2</li>
</ul>
</code></pre><h5 id="strukturierung-von-textinhalten-absätze-richtig-nutzen-1">Absätze richtig nutzen</h5>
<p>Um Absätze in HTML korrekt darzustellen, verwenden Sie das <code><p></code>-Tag. Dieses Tag sorgt dafür, dass der Text in logische Abschnitte unterteilt wird und von Browsern sowie assistiven Technologien richtig interpretiert werden kann.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-2">Beispiel:</h6>
<pre tabindex="0"><code><p>Barrierefreiheit ist wichtig, um allen Nutzenden Zugang zu digitalen Inhalten zu ermöglichen. </p>
<p>Die richtige Strukturierung von Absätzen verbessert die Lesbarkeit. </p>
</code></pre><h5 id="strukturierung-von-textinhalten-verlinkungen-richtig-umsetzen">Verlinkungen richtig umsetzen</h5>
<p>Um Verlinkungen in HTML zu erstellen, verwenden Sie das <code><a></code>-Tag (Anker-Tag). Dieses Tag ermöglicht es Ihnen, Text oder Bilder als Hyperlink zu definieren.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-3">Beispiel:</h6>
<pre tabindex="0"><code><p>Für weitere Informationen zur <strong>Barrierefreiheit</strong> besuchen Sie bitte die <a href="https://www.bfit-bund.de">Webseite der BFIT</a>. <;/p>
<p>Kontaktieren Sie uns unter <a href="mailto:info@bfit-bund.de">info@bfit-bund.de</a>. </p>
</code></pre><h5 id="strukturierung-von-textinhalten-textauszeichnung-richtig-umsetzen">Textauszeichnung richtig umsetzen</h5>
<p>Um Text in HTML hervorzuheben, verwenden Sie die Tags <code><strong></code> für fett und <code><em></code> für kursiv. Diese Tags geben nicht nur visuelle Hinweise, sondern tragen auch zur semantischen Bedeutung des Textes bei.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-4">Beispiel:</h6>
<pre tabindex="0"><code><p>Die <strong>Barrierefreiheit</strong> ist entscheidend, um allen Nutzenden den Zugang zu erleichtern. </p>
<p>Wichtige Informationen sollten <em>hervorgehoben</em> werden, um die Lesbarkeit zu erhöhen. </p>
</code></pre><h5 id="strukturierung-von-textinhalten-tabellen-korrekt-verwenden">Tabellen korrekt verwenden:</h5>
<p>Setzen Sie Spaltenüberschriften mit <th> und Datenzellen mit <td>.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-5">Beispiel:</h6>
<pre tabindex="0"><code><table>
<tr>
<th>Spaltenüberschrift 1</th>
<th>Spaltenüberschrift 2</th>
</tr>
<tr>
<td>Daten 1</td>
<td>Daten 2</td>
</tr>
</table>
</code></pre><h4 id="strukturierung-von-textinhalten-microsoft-word">Microsoft Word</h4>
<h5 id="strukturierung-von-textinhalten-überschriften-setzen">Überschriften setzen:</h5>
<p>Verwenden Sie die integrierten Formatvorlagen (Überschrift 1, Überschrift 2, etc.), um die Struktur deutlich zu machen. Diese Formate sind für assistive Technologien erkennbar und helfen, den Text hierarchisch zu gliedern.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-6">Beispiel:</h6>
<ul>
<li><p>Überschrift 1: “Barrierefreie Webseiten erstellen”
</p><ul>
<li><p>Überschrift 2: “Wichtige WCAG-Erfolgskriterien”
</p><ul>
<li><p>Überschrift 3: “WCAG 2.4.4 – Linkzweck im Kontext”</p></li>
</ul>
</li>
</ul>
</li>
</ul>
<h6 id="strukturierung-von-textinhalten-in-word">In Word:</h6>
<ol>
<li><p>Markiere Sie den Text, der eine Überschrift sein soll.</p></li>
<li><p>Wählen Sie im Reiter Start die entsprechende Formatvorlage (Überschrift 1, 2, 3 usw.) aus.</p></li>
</ol>
<h5 id="strukturierung-von-textinhalten-absätze-richtig-verwenden">Absätze richtig verwenden</h5>
<p>Anstatt Leerzeichen zu verwenden, um Abstände zwischen Absätzen zu erzeugen, sollten Sie die integrierte Absatzfunktion nutzen. Dadurch wird sichergestellt, dass der Text korrekt strukturiert ist und von assistiven Technologien richtig interpretiert wird. Das Drücken von Enter fügt automatisch einen neuen Absatz ein, ohne dass zusätzliche Leerzeichen nötig sind.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-7">Beispiel:</h6>
<p>Absatz 1: “Barrierefreiheit ist wichtig, um allen Nutzenden Zugang zu digitalen Inhalten zu ermöglichen.”
Absatz 2: “Die richtige Strukturierung von Absätzen verbessert die Lesbarkeit.”</p>
<h6 id="strukturierung-von-textinhalten-in-word-1">In Word:</h6>
<ol>
<li><p>Schreiben Sie Ihren Text.</p></li>
<li><p>Setzen Sie den Cursor an das Ende des Satzes und drücken Sie Enter, um einen neuen Absatz zu beginnen.</p></li>
<li><p>Um den Abstand zwischen Absätzen anzupassen: Gehen Sie zu Start > Absatz > Abstand vor/nach und stellen Sie den gewünschten Abstand ein.</p></li>
</ol>
<h5 id="strukturierung-von-textinhalten-listen-nutzen">Listen nutzen:</h5>
<p>Anstatt manuell Bindestriche zu setzen, sollten Sie die integrierte „Aufzählung“ oder „Nummerierung“ Funktion verwenden, um Listen zu erstellen. Dies sorgt dafür, dass Screenreader die Listenstruktur korrekt interpretieren können.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-8">Beispiel:</h6>
<p>Aufzählung:</p>
<ul>
<li><p>Barrierefreiheit prüfen</p></li>
<li><p>Inhalte strukturieren</p></li>
<li><p>Alt-Texte hinzufügen
<br></p></li>
</ul>
<p>Nummerierte Liste:</p>
<ol>
<li><p>Barrierefreiheit prüfen</p></li>
<li><p>Inhalte strukturieren</p></li>
<li><p>Alt-Texte hinzufügen</p></li>
</ol>
<h6 id="strukturierung-von-textinhalten-in-word-2">In Word:</h6>
<ol>
<li><p>Markieren Sie den Text, der zur Liste werden soll.</p></li>
<li><p>Wählen Sie im Reiter Start die Option Aufzählung (für ungeordnete Listen) oder Nummerierung (für geordnete Listen).</p></li>
</ol>
<h5 id="strukturierung-von-textinhalten-verlinkungen-einfügen">Verlinkungen einfügen</h5>
<p>Um Verlinkungen in Word einzufügen, verwenden Sie die Funktion zum Erstellen von Hyperlinks. Dies ermöglicht es Ihnen, Texte oder Bilder mit einer Webseite, einem Dokument oder einer E-Mail-Adresse zu verknüpfen.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-9">Beispiel:</h6>
<p>“Für weitere Informationen zur Barrierefreiheit besuchen Sie bitte die Webseite der BFIT.”</p>
<h6 id="strukturierung-von-textinhalten-in-word-3">In Word:</h6>
<ol>
<li><p>Markieren Sie den Text oder das Bild, das Sie verlinken möchten.</p></li>
<li><p>Klicken Sie mit der rechten Maustaste und wählen Sie Hyperlink aus dem Kontextmenü oder gehen Sie zu Einfügen > Link > Hyperlink.</p></li>
<li><p>Geben Sie die URL oder die Zieladresse ein und bestätigen Sie mit OK.</p></li>
</ol>
<h5 id="strukturierung-von-textinhalten-textauszeichnung-richtig-umsetzen-1">Textauszeichnung richtig umsetzen</h5>
<p>Um Text in Word hervorzuheben, verwenden Sie die Funktionen für <strong>fett</strong> und <strong>kursiv</strong>. Diese Auszeichnungen helfen, wichtige Informationen zu betonen und die Lesbarkeit zu verbessern.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-10">Beispiel:</h6>
<p>“Die Barrierefreiheit ist <em>entscheidend</em>, um allen Nutzenden den Zugang zu erleichtern.”
“Wichtige Informationen sollten <strong>hervorgehoben</strong> werden, um die Lesbarkeit zu erhöhen.”</p>
<h6 id="strukturierung-von-textinhalten-word">Word:</h6>
<ol>
<li><p>Markieren Sie den Text, den Sie auszeichnen möchten.</p></li>
<li><p>Verwenden Sie die Tastenkombinationen Strg + B für <strong>Fett</strong> oder Strg + I für <strong>Kursiv.</strong> Alternativ können Sie im Reiter Start die entsprechenden Symbole für Fett (B) oder Kursiv (I) auswählen.</p></li>
</ol>
<h5 id="strukturierung-von-textinhalten-tabellen-richtig-verwenden">Tabellen richtig verwenden:</h5>
<p>Verwenden Sie die Tabellenfunktion und setzen Sie klar definierte Spalten- und Zeilenüberschriften. Markieren Sie die Tabellenüberschriften als solche, um die Barrierefreiheit zu gewährleisten.</p>
<h6 id="strukturierung-von-textinhalten-beispiel-word-tabellen">Beispiel Word Tabellen:</h6>
<table>
<caption>
<p>Tabelle 1 Beispieltabelle</p>
</caption>
<colgroup>
<col style="width: 33%" />
<col style="width: 33%" />
<col style="width: 33%" />
</colgroup>
<thead>
<tr>
<th>Name</th>
<th>Alter</th>
<th>Stadt</th>
</tr>
</thead>
<tbody>
<tr>
<td>Max Mustermann</td>
<td>30</td>
<td>Berlin</td>
</tr>
<tr>
<td>Anna Schmidt</td>
<td>25</td>
<td>München</td>
</tr>
</tbody>
</table>
<h6 id="strukturierung-von-textinhalten-in-word-4">In Word:</h6>
<ol>
<li><p>Erstellen Sie die Tabelle unter Einfügen > Tabelle.</p></li>
<li><p>Wählen Sie auf der Registerkarte Entwurf die Gruppe Optionen für Tabellenformatvorlagen und dann Kopfzeile und ggf. erste Spalte aus.</p></li>
</ol>
<h3 id="strukturierung-von-textinhalten-weitere-informationen">Weitere Informationen</h3>
<p>Zusätzliche Informationen finden Sie in unseren Handreichungen unter folgenden Links:</p>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/bf-dokumente-lernkontext/tabellen.html">Hinweise zur Gestaltung von Tabellen</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/bgwa/webseitenstruktur.html">Webseitenstruktur</a></p></li>
</ul>
<h3 id="strukturierung-von-textinhalten-checkliste-zur-strukturierung-von-textinhalten">Checkliste zur Strukturierung von Textinhalten</h3>
<h4 id="strukturierung-von-textinhalten-überschriftenhierarchie-h1---h6-1">Überschriftenhierarchie (H1 - H6)</h4>
<ul>
<li><p><strong>Eine Hauptüberschrift verwenden</strong>:<br>
Stellen Sie sicher, dass jede Webseite oder jedes Dokument eine klare Hauptüberschrift hat, die das Thema deutlich angibt.</p></li>
<li><p><strong>Hierarchie einhalten</strong>:<br>
Verwenden Sie eine klare Hierarchie von Unterüberschriften:
</p><ul>
<li><p><strong>H1</strong> für Hauptkapitel oder Themenbereiche</p></li>
<li><p><strong>H2</strong> für Unterkapitel innerhalb eines Themenbereichs</p></li>
<li><p><strong>H3-H6</strong> für detailliertere Unterpunkte</p></li>
</ul>
</li>
<li><p><strong>Überschriften nicht aus visuellen Gründen nutzen</strong>:<br>
Verwenden Sie Überschriften ausschließlich zur Organisation der Inhalte, nicht zur Gestaltung. Vermeiden Sie es, Überschriftenformate zu verwenden, um visuelle Effekte zu erzielen.</p></li>
<li><p><strong>Dokumentenformatvorlagen nutzen</strong>:
Wenn Sie in Word oder einem anderen Dokumentenformat arbeiten, verwenden Sie die entsprechenden Formatvorlagen für Titel und Überschriften.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-absätze-richtig-nutzen-2">Absätze richtig nutzen</h4>
<ul>
<li><p><strong>Kurze und prägnante Absätze erstellen</strong>:<br>
Vermeiden Sie lange Textblöcke und teilen Sie den Text in kurze, thematisch zusammenhängende Absätze auf. Jeder Absatz sollte einen klaren Gedanken oder ein Thema enthalten.</p></li>
<li><p><strong>Leere Zeilen vermeiden</strong>:<br>
Nutzen Sie semantisch korrekte Absätze:
</p><ul>
<li><p>Verwenden Sie <code><p></code>-Tags für neue Absätze, um neue Themen oder Gedanken zu kennzeichnen.</p></li>
<li><p>Vermeiden Sie einfache Zeilenumbrüche <code>(<br>)</code> für die inhaltliche Trennung.</p></li>
<li><p><strong>In Word</strong>: Drücken Sie Enter, um einen neuen Absatz zu beginnen.</p></li>
</ul>
</li>
</ul>
<h4 id="strukturierung-von-textinhalten-listen-und-aufzählungen-1">Listen und Aufzählungen</h4>
<ul>
<li><p><strong>Geeignete Listen verwenden</strong>:
Nutzen Sie Listen, um Informationen übersichtlich und leicht verständlich zu präsentieren.
</p><ul>
<li><p>Verwenden Sie nummerierte Listen <code>(<ol>)</code> für eine bestimmte Reihenfolge oder Priorität.</p></li>
<li><p>Verwenden Sie <strong>ungeordnete Listen</strong> <code>(<ul>)</code>für Aufzählungen ohne Reihenfolge.</p></li>
<li><p><strong>In Word</strong>: Verwenden Sie die Aufzählung oder Nummerierung Funktion im Reiter Start.</p></li>
</ul>
</li>
<li><p><strong>Aufzählungen sinnvoll gestalten</strong>:
Stellen Sie sicher, dass die Elemente in der Liste klar und prägnant sind, um die Lesbarkeit zu verbessern.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-tabellen-1">Tabellen</h4>
<ul>
<li><p><strong>Tabellen für Daten verwenden</strong>:
Verwenden Sie Tabellen ausschließlich zur Darstellung von tabellarischen Daten, nicht für das Layout von Inhalten.</p></li>
<li><p><strong>Überschriften für Spalten und Zeilen setzen</strong>:
Markieren Sie die Überschriften, um die Struktur der Tabelle zu verdeutlichen.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-verlinkungen-1">Verlinkungen</h4>
<ul>
<li><p><strong>Aussagekräftige Linktexte verwenden</strong>:
Der Linktext sollte klar und beschreibend sein, sodass die Nutzenden den Zweck des Links verstehen können.</p></li>
<li><p><strong>Vermeiden Sie Formulierungen wie</strong> „Klicken Sie hier“. Nutzen Sie stattdessen konkrete Texte wie „Mehr erfahren über Barrierefreiheit“.</p></li>
</ul>
<h4 id="strukturierung-von-textinhalten-textauszeichnung-z-b-fett-und-kursiv-1">Textauszeichnung (z. B. Fett und Kursiv)</h4>
<ul>
<li><p><strong>Fett- und Kursivschrift sparsam verwenden</strong>:
Verwenden Sie das <code><strong></code>-Tag für fette Schrift und <code><em></code>für kursiv, um wichtige Informationen hervorzuheben.</p></li>
<li><p><strong>In Word</strong>: Markieren Sie den Text und verwenden Sie Strg + B für fett oder Strg + I für kursiv.</p></li>
<li><p><strong>Übertreibungen vermeiden</strong>:
Heben Sie nur die wichtigsten Informationen hervor, um die Lesbarkeit nicht zu beeinträchtigen.</p></li>
<li><p><strong>Konsistenz gewährleisten</strong>:<br>
Achten Sie darauf, dass die Verwendung von Textauszeichnungen im gesamten Dokument konsistent ist.</p></li>
</ul>
<h2 id="untertitel-für-barrierefreie-inhalte">Untertitel für barrierefreie Inhalte</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/untertitel.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_untertitel.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../untertitel/image2.png" style="" alt="" />
<h3 id="untertitel-für-barrierefreie-inhalte-was-sind-eigentlich-untertitel">Was sind eigentlich Untertitel?</h3>
<p>Untertitel sind Textzeilen, die den gesprochenen Inhalt eines Videos oder Films wiedergeben. Sie erscheinen synchron zum gesprochenen Wort am unteren Rand des Bildschirms und bieten eine schriftliche Darstellung der Audioinhalte. Untertitel machen Videos für ein breiteres Publikum zugänglich, insbesondere für Menschen mit Hörbeeinträchtigungen oder Sprachbarrieren.</p>
<h3 id="untertitel-für-barrierefreie-inhalte-warum-sind-untertitel-wichtig">Warum sind Untertitel wichtig?</h3>
<p>Untertitel sind ein zentraler Bestandteil digitaler Barrierefreiheit. Sie ermöglichen es Menschen mit Hörbeeinträchtigungen, audiovisuelle Inhalte zu verstehen. Darüber hinaus profitieren auch andere Zielgruppen wie Menschen in lauten Umgebungen oder solche, die Videos in einer Fremdsprache schauen.</p>
<h3 id="untertitel-für-barrierefreie-inhalte-zielgruppen-die-von-untertiteln-profitieren">Zielgruppen, die von Untertiteln profitieren:</h3>
<ul>
<li><p><strong>Menschen mit Hörbehinderungen</strong>: Untertitel ermöglichen den Zugang zu Audioinhalten.</p></li>
<li><p><strong>Fremdsprachige Nutzende</strong>: Übersetzte Untertitel erweitern die Reichweite von Inhalten.</p></li>
<li><p>Menschen, die z. B. bei einer Live-Veranstaltung aufgrund von Nebengeräuschen das Audio schlecht hören können.</p></li>
<li><p><strong>Alle Nutzenden</strong>: Untertitel können in geräuschvollen oder ruhigen Umgebungen nützlich sein.</p></li>
</ul>
<h3 id="untertitel-für-barrierefreie-inhalte-welche-arten-von-untertiteln-gibt-es">Welche Arten von Untertiteln gibt es?</h3>
<p>Es gibt grundsätzlich zwei Arten von Untertiteln:</p>
<ul>
<li><p><strong>Closed Captions</strong>: Diese Untertitel können vom Benutzenden ein- und ausgeblendet werden. Ein großer Vorteil von Closed Captions ist, dass sie nicht nur ein- und ausgeblendet, sondern mittlerweile in vielen Playern auch individuell konfiguriert werden können. So kann beispielsweise die Schriftfarbe oder die Schriftgröße verändert werden. Closed Captions sind besonders wichtig für die digitale Barrierefreiheit, da sie von assistiven Technologien ausgelesen werden können. Dadurch können auch taubblinde Menschen die Untertitel lesen.</p></li>
<li><p><strong>Open Captions</strong>: Diese Untertitel sind fest in den Film eingebrannt und können nicht vom Benutzenden ausgeblendet oder verändert werden. Sie sind Teil der Bildinformation und können von assistiven Technologien nicht ausgelesen werden. Daher sind Open Captions nicht von allen Menschen wahrnehmbar und sollten nach Möglichkeit vermieden werden.</p></li>
<li><p><strong>Live Captions</strong>: Live Captions werden in Echtzeit während eines Events, einer Präsentation oder eines Meetings generiert und angezeigt. Sie basieren häufig auf automatischer Spracherkennung und sind direkt mit dem gesprochenen Inhalt synchronisiert. Da sie automatisch und spontan erstellt werden, können Live Captions Ungenauigkeiten oder Verzögerungen aufweisen. Diese Untertitel sind nicht statisch im Video eingebunden, sondern werden live dargestellt und aktualisiert. Assistive Technologien wie Screenreader können Live Captions in der Regel nicht auslesen, da sie oft nur visuell auf dem Bildschirm erscheinen.</p></li>
</ul>
<h3 id="untertitel-für-barrierefreie-inhalte-rechtliche-grundlage-für-untertitel">Rechtliche Grundlage für Untertitel</h3>
<p>Untertitel spielen eine entscheidende Rolle bei der barrierefreien Gestaltung digitaler Inhalte. Sie gewährleisten, dass audiovisuelle Medien für Menschen mit Hörbeeinträchtigungen zugänglich sind und verbessern insgesamt die Verständlichkeit von Inhalten. Die rechtlichen Anforderungen an Untertitel werden durch verschiedene Normen und Richtlinien festgelegt, insbesondere durch die Europäische Norm EN 301 549 und die Web Content Accessibility Guidelines (WCAG). In Deutschland werden die Anforderungen der EN 301 549 in § 3 Absatz 2 in der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) genannt.</p>
<h4 id="untertitel-für-barrierefreie-inhalte-en-301-549---71-technologie-zur-verarbeitung-von-untertiteln">EN 301 549 - 7.1: Technologie zur Verarbeitung von Untertiteln</h4>
<p>Die EN 301 549 legt die Barrierefreiheitsanforderungen für Informations- und Kommunikationstechnologie (IKT) Produkte und -Dienstleistungen fest. In Abschnitt 7.1 werden spezifische Anforderungen an Untertitel definiert, darunter:</p>
<ul>
<li><p><strong>Bereitstellung von Untertiteln</strong>: Für alle aufgezeichneten und live übertragenen Videos mit gesprochenem Inhalt müssen Untertitel bereitgestellt werden, um Menschen mit Hörbeeinträchtigungen den Zugang zu ermöglichen.</p></li>
<li><p><strong>Synchronisation</strong>: Untertitel müssen synchron zum gesprochenen Inhalt angezeigt werden, um ein kohärentes Verständnis zu gewährleisten.</p></li>
<li><p><strong>Anpassbarkeit</strong>: Nutzende sollten die Möglichkeit haben, Eigenschaften der Untertitel wie Größe, Kontrast, Transparenz des Hintergrunds, Schriftart oder Position an ihre individuellen Bedürfnisse anzupassen.</p></li>
</ul>
<h4 id="untertitel-für-barrierefreie-inhalte-web-content-accessibility-guidelines-wcag----relevante-erfolgskriterien">Web Content Accessibility Guidelines (WCAG) – Relevante Erfolgskriterien</h4>
<p>Die WCAG sind international anerkannte Richtlinien zur barrierefreien Gestaltung von Webinhalten. Sie definieren Erfolgskriterien, die für die Bereitstellung von Untertiteln relevant sind:</p>
<ul>
<li><p><strong>Erfolgskriterium 1.2.2 – Untertitel (aufgezeichnet)</strong>: Für alle aufgezeichneten Videos mit gesprochenem Inhalt müssen Untertitel bereitgestellt werden, um Menschen mit Hörbeeinträchtigungen den Zugang zu ermöglichen.</p></li>
<li><p><strong>Erfolgskriterium 1.2.4 – Untertitel (Live)</strong>: Für Live-Audioinhalte müssen in Echtzeit Untertitel bereitgestellt werden, damit auch Menschen mit Hörbeeinträchtigungen diese Inhalte verfolgen können.</p></li>
</ul>
<h3 id="untertitel-für-barrierefreie-inhalte-wie-erstellt-man-barrierefreie-untertitel">Wie erstellt man barrierefreie Untertitel?</h3>
<ol>
<li><p>Transkription des gesprochenen Inhalts
</p><ul>
<li><p>Ist der gesamte gesprochene Text des Videos Wort für Wort transkribiert?</p></li>
<li><p>Sind relevante Geräusche (z. B. “[Türknallen]”, “[Lachen]”) ergänzt, die für das Verständnis wichtig sind?</p></li>
<li><p>Wurden automatische Untertitelungsfunktionen genutzt und nachträglich überprüft sowie angepasst?</p></li>
</ul>
</li>
<li><p>Timing und Synchronisierung
</p><ul>
<li><p>Sind die Untertitel synchron mit dem gesprochenen Text?</p></li>
<li><p>Erscheinen die Untertitel im richtigen Moment und verschwinden, sobald die Aussage beendet ist?</p></li>
</ul>
</li>
<li><p>Formatierung der Untertitel
</p><ul>
<li><p>Ist das Schriftbild gut lesbar und hebt sich deutlich vom Hintergrund ab? (Besonders wichtig bei Open Captions)</p></li>
<li><p>Sind die Untertitel kurzgehalten (max. zwei Zeilen)?</p></li>
<li><p>Sind die Untertitel des Videos so positioniert, dass wichtige visuelle Inhalte nicht verdeckt werden?</p></li>
</ul>
</li>
<li><p>Bereitstellung in verschiedenen Formaten
</p><ul>
<li><p>Werden die Untertitel in Formaten wie .srt, .vtt oder .txt bereitgestellt?</p></li>
<li><p>Ist das Format an die jeweilige Plattform angepasst?</p></li>
</ul>
</li>
<li><p>Fehlerfreie Umsetzung sicherstellen
</p><ul>
<li><p>Sind Grammatik und Rechtschreibung fehlerfrei?</p></li>
<li><p>Wurde ein hoher Kontrast zwischen Text und Hintergrund sichergestellt, damit die Untertitel in allen Szenen des Videos klar lesbar sind? (Vorwiegend für Open Captions relevant)</p></li>
</ul>
</li>
<li><p>Qualität der Untertitel testen</p></li>
</ol>
<ul>
<li><p>Test: Schaut das Video mit Untertiteln an und schaltet den Ton aus. Ist der Inhalt allein durch die Untertitel gut verständlich? Wenn ja, erfüllen die Untertitel die Anforderungen für Barrierefreiheit und sind für alle Zielgruppen hilfreich.</p></li>
</ul>
<h3 id="untertitel-für-barrierefreie-inhalte-hinweis">Hinweis:</h3>
<p>Bei <strong>Open Captions</strong> (offenen Untertiteln), die fest in das Video integriert sind, werden Kontrasteinstellungen und Formatierungen während der Videoproduktion festgelegt. Im Gegensatz dazu sind bei <strong>Closed Captions</strong> (geschlossenen Untertiteln) die Anpassungsmöglichkeiten für Nutzer:innen oft eingeschränkt, da die Anzeigeeigenschaften vom verwendeten Player vorgegeben werden.</p>
<h3 id="untertitel-für-barrierefreie-inhalte-weitere-informationen">Weitere Informationen:</h3>
<ul>
<li><p><a href="https://www.w3.org/WAI/media/av/captions/">Captions/Subtitles | Web Accessibility Initiative (WAI) | W3C</a></p></li>
<li><p><a href="https://www.daserste.de/specials/service/untertitel-standards100.html">Untertitel-Standards - ARD | Das Erste</a></p></li>
</ul>
<h3 id="untertitel-für-barrierefreie-inhalte-checkliste-für-barrierefreie-untertitel">Checkliste für barrierefreie Untertitel</h3>
<ol>
<li><p>Transkription</p></li>
</ol>
<ul>
<li><p>Ist der gesprochene Text vollständig transkribiert? </p></li>
<li><p>Sind relevante Geräusche (z. B. „Türknallen“, „Lachen“ oder „Musik“) ergänzt?</p></li>
<li><p>Wurden automatische Untertitel geprüft und angepasst? </p></li>
</ul>
<ol start="2">
<li><p>Timing und Synchronisation</p></li>
</ol>
<ul>
<li><p>Stimmen die Untertitel zeitlich mit dem gesprochenen Text überein?</p></li>
<li><p>Verschwinden die Untertitel, sobald die Aussage beendet ist?</p></li>
</ul>
<ol start="3">
<li><p>Formatierung</p></li>
</ol>
<ul>
<li><p>Ist die Schrift gut lesbar und hebt sich vom Hintergrund ab? (besonders wichtig bei Open Captions)</p></li>
<li><p>Sind die Untertitel kurz (max. 2 Zeilen) und unten im Video platziert?</p></li>
</ul>
<ol start="4">
<li><p>Bereitstellung</p></li>
</ol>
<ul>
<li><p>Sind Untertitel im richtigen Format (.srt, .vtt oder .txt) für die jeweilige Plattform vorhanden?</p></li>
</ul>
<ol start="5">
<li><p>Qualität sicherstellen</p></li>
</ol>
<ul>
<li><p>Sind Rechtschreibung und Grammatik korrekt?</p></li>
<li><p>Ist der Kontrast zwischen Text und Hintergrund ausreichend?</p></li>
<li><p>Test: Video mit Untertiteln ohne Ton ansehen – ist der Inhalt verständlich?</p></li>
</ul>
<h2 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit">Werkzeuge zur Überprüfung der digitalen Barrierefreiheit</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/redaktion/werkzeuge-zur-ueberpruefung-barrierefreiheit.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_werkzeuge_zur_ueberpruefung_barrierefreiheit.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/undraw_pen-tool_sbiz.png" style="" alt="" />
<h3 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-einleitung">Einleitung</h3>
<p>Die Sicherstellung der digitalen Barrierefreiheit ist ein essenzieller Bestandteil moderner Webentwicklung.</p>
<p>Um die Barrierefreiheit eurer eigenen Webseite oder digitalen Inhalte einfach zu testen, gibt es eine Vielzahl an hilfreichen Tools. In diesem Guide stellen wir euch eine umfassende Sammlung von Werkzeugen vor, erklären ihre Funktionsweise und geben praktische Beispiele für ihre Anwendung. Zudem wird erläutert, welche WCAG-Erfolgskriterien durch diese Tools überprüft werden können und welche Nutzergruppen davon profitieren.</p>
<p>Ziel dieses Guides ist es, euch einfache Hilfsmittel an die Hand zu geben, mit denen ihr die Barrierefreiheit eurer Seite schnell und effizient bewerten könnt.</p>
<p>Die folgenden Werkzeuge stellen nur eine kleine Auswahl der verfügbaren Tools dar und sind aktuell alle kostenlos. </p>
<h3 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-bookmarklets">Bookmarklets</h3>
<p>Bookmarklets sind kleine JavaScripte, die als Lesezeichen im Browser gespeichert werden. Sie ermöglichen eine schnelle Analyse von Webseiten, ohne zusätzliche Software installieren zu müssen. Diese Tools unterstützen dabei, Inhalte auf Barrierefreiheit zu prüfen. Nun stellen wir 5 von diesen vor, diese sind in der Liste von <a href="https://tollwerk.github.io/a11y-bookmarklets/">Tollwerk</a> zu finden.</p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-landmarks-bookmarklet----strukturierte-navigation-für-screenreader">Landmarks Bookmarklet – Strukturierte Navigation für Screenreader</h4>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wieso-ist-dies-nützlich-für-die-barrierefreiheit">Wieso ist dies nützlich für die Barrierefreiheit?</h5>
<p>Landmarks bieten eine semantische Struktur für Webseiten und erleichtern die Navigation für Screenreader-Nutzende erheblich. Sie ermöglichen es Nutzenden, gezielt zwischen wichtigen Bereichen wie Kopfzeile, Navigation und Hauptinhalt zu springen, ohne sich durch unnötige Elemente bewegen zu müssen.</p>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-welche-wcag-erfolgskriterienwerden-geprüft">Welche WCAG-Erfolgskriterien werden geprüft?</h5>
<ul>
<li><p>1.3.1 Info und Beziehungen</p></li>
</ul>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-beispiel">Beispiel</h5>
<p>Nach Aktivierung hebt das Bookmarklet alle Landmarks auf einer Webseite visuell hervor und zeigt an, ob die richtigen HTML-Elemente für Navigation und Strukturierung genutzt wurden. Dadurch kann überprüft werden, ob Screenreader eine sinnvolle Seitenstruktur erfassen können.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/Landmark.png" style="" alt="" />
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-headings-bookmarklet----prüfung-der-überschriftenhierarchie">Headings Bookmarklet – Prüfung der Überschriftenhierarchie</h4>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wieso-ist-dies-nützlich-für-die-barrierefreiheit-1">Wieso ist dies nützlich für die Barrierefreiheit?</h5>
<p>Eine korrekte Überschriftenstruktur hilft Screenreadern, den Aufbau einer Webseite zu erfassen und erleichtert allen Nutzenden die Navigation. Eine logische Hierarchie verbessert das Verständnis und die Orientierung auf der Seite.</p>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-welchewcag-erfolgskriterien-werden-geprüft">Welche WCAG-Erfolgskriterien werden geprüft?</h5>
<ul>
<li><p>1.3.1 Info und Beziehungen</p></li>
<li><p>2.4.6 Überschriften und Beschriftungen</p></li>
</ul>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-beispiel-1">Beispiel</h5>
<p>Dieses Bookmarklet zeigt eine strukturierte Liste aller Überschriften (h1 bis h6) auf einer Webseite an und markiert hierarchische Fehler. So lässt sich schnell erkennen, ob die Überschriften sinnvoll verwendet wurden.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/Heading.png" style="" alt="" />
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-images-bookmarklet----überprüfung-von-alternativtexten">Images Bookmarklet – Überprüfung von Alternativtexten</h4>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wieso-ist-dies-nützlich-für-die-barrierefreiheit-2">Wieso ist dies nützlich für die Barrierefreiheit?</h5>
<p>Alternativtexte sind essenziell für blinde oder sehbehinderte Nutzende, um den Inhalt von Bildern zu verstehen. Fehlende oder ungenaue Alternativtexte können dazu führen, dass wichtige Informationen nicht wahrgenommen werden können.</p>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-welche-wcag-kriterien-werden-geprüft">Welche WCAG-Kriterien werden geprüft?</h5>
<ul>
<li><p>1.1.1 Nicht-Text-Inhalte</p></li>
</ul>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-beispiel-2">Beispiel</h5>
<p>Das Bookmarklet hebt alle Bilder ohne Alternativtext hervor und zeigt deren alt-Attribute an. Es hilft dabei, unzureichende oder fehlende Beschreibungen zu identifizieren und ermöglicht so eine Optimierung der Bildbeschreibungen für Screenreader-Nutzende.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/Alt.png" style="" alt="" />
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-forms-bookmarklet----prüfung-von-formularfeldern">Forms Bookmarklet – Prüfung von Formularfeldern</h4>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wieso-ist-dies-nützlich-für-die-barrierefreiheit-3">Wieso ist dies nützlich für die Barrierefreiheit?</h5>
<p>Formulare müssen für alle Nutzenden zugänglich sein. Fehlende oder unzureichende Beschriftungen von Formularfeldern erschweren Menschen mit Sehbeeinträchtigungen die Nutzung, insbesondere wenn sie Screenreader verwenden. Eine korrekte Struktur hilft allen Nutzenden bei der Eingabe und Orientierung.</p>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-welchewcag-erfolgskriterien-werden-geprüft-1">Welche WCAG-Erfolgskriterien werden geprüft?</h5>
<ul>
<li><p>1.3.1 Info und Beziehungen</p></li>
<li><p>3.3.2 Beschriftungen von Formularelementen vorhanden</p></li>
</ul>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-beispiel-3">Beispiel</h5>
<p>Dieses Bookmarklet hebt Formularfelder hervor und zeigt an, ob Beschriftungen korrekt mit den Eingabefeldern verknüpft sind.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/Form.png" style="" alt="" />
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-focus-bookmarklet----sichtbarkeit-des-tastaturfokus-prüfen">Focus Bookmarklet – Sichtbarkeit des Tastaturfokus prüfen</h4>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wieso-ist-dies-nützlich-für-die-barrierefreiheit-4">Wieso ist dies nützlich für die Barrierefreiheit?</h5>
<p>Menschen, die eine Webseite ausschließlich mit der Tastatur bedienen, benötigen eine deutliche Fokusmarkierung, um zu erkennen, welches Element aktuell aktiv ist. Fehlt diese visuelle Rückmeldung, kann die Navigation erheblich erschwert werden.</p>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-welche-wcag-erfolgskriterien-werden-geprüft">Welche WCAG-Erfolgskriterien werden geprüft?</h5>
<ul>
<li><p>2.4.7 Fokus sichtbar</p></li>
<li><p>2.4.3 Fokusreihenfolge</p></li>
</ul>
<h5 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-beispiel-4">Beispiel</h5>
<p>Das Bookmarklet hebt das aktuell fokussierte Element farblich hervor. Dadurch kann überprüft werden, ob sich der Fokus beim Navigieren mit der Tab-Taste logisch bewegt und stets sichtbar bleibt.</p>
<img src="../werkzeuge-zur-ueberpruefung-barrierefreiheit/Focus.png" style="" alt="" />
<h3 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-manuelle-testwerkzeuge">Manuelle Testwerkzeuge</h3>
<p>Diese Tools ermöglichen es, Webseiten durch direkte Interaktion zu testen und helfen insbesondere Entwicklern sowie Testern, Barrierefreiheit aus der Perspektive der Nutzenden zu bewerten.</p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-nvda-nonvisual-desktop-access">NVDA (NonVisual Desktop Access)</h4>
<p>NVDA ist ein kostenloser und quelloffener Screenreader für Windows, der Menschen mit Sehbeeinträchtigungen den Zugriff auf digitale Inhalte ermöglicht. Er liest Bildschirminhalte laut vor, gibt akustische Rückmeldungen zu Elementen wie Links, Überschriften und Formularfeldern und erlaubt Nutzenden die Steuerung von Anwendungen über Sprachausgabe und Braillezeilen. Entwickler und Testende können mit NVDA überprüfen, ob ihre Webseiten korrekt für Screenreader strukturiert sind und ob alle interaktiven Elemente barrierefrei bedienbar sind. Mithilfe der Tabulatortaste oder Pfeiltasten kann geprüft werden, ob die Fokusreihenfolge logisch ist, Alternativtexte für Bilder vorhanden sind und interaktive Elemente wie Buttons oder Links für blinde Nutzende verständlich beschriftet wurden.</p>
<p><strong>Unter diesem Link downloadbar</strong>: <a href="https://www.nvaccess.org/download/">NV Access | Download NVDA</a></p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-colour-contrast-analyser-cca">Colour Contrast Analyser (CCA)</h4>
<p>Der Colour Contrast Analyser (CCA) ist ein Tool zur Überprüfung des Farbkontrasts zwischen Vorder- und Hintergrundfarben. Ein ausreichender Kontrast ist essenziell für Menschen mit Sehbeeinträchtigungen, insbesondere für Personen mit Farbsehschwächen oder altersbedingten Sehproblemen. Der CCA ermöglicht es, Farbwerte direkt vom Bildschirm zu messen und diese mit den WCAG-Richtlinien zu vergleichen, um sicherzustellen, dass Texte und interaktive Elemente für alle Nutzenden gut lesbar sind. Man kann mit dem CCA zwei Farben auf einer Webseite auswählen (z. B. Schriftfarbe und Hintergrundfarbe) und überprüfen, ob das Kontrastverhältnis den Anforderungen von WCAG 1.4.3 (Kontrast-Minimum) entspricht. Das Tool zeigt an, ob der Kontrast ausreicht und gibt Hinweise zur Verbesserung der Lesbarkeit.</p>
<p><strong>Unter diesem Link downloadbar</strong>: <a href="https://www.accessibility-developer-guide.com/setup/helper-tools/colour-contrast-analyser/">Colour Contrast Analyser</a></p>
<h3 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-automatisierte-testwerkzeuge">Automatisierte Testwerkzeuge</h3>
<p>Automatisierte Tools ermöglichen eine schnelle und umfassende Analyse von Webseiten und helfen, Barrierefreiheitsprobleme zu erkennen sowie Prioritäten für deren Behebung festzulegen. Sie sind ein wertvolles Hilfsmittel, insbesondere als erster Einstieg in die Barrierefreiheitsprüfung.</p>
<p>Allerdings haben diese Tools auch klare Einschränkungen. Sie erkennen nur einen Teil der Barrierefreiheitsprobleme, insbesondere solche, die sich technisch überprüfen lassen. Komplexere Barrieren bleiben oft unentdeckt. Zudem können automatisierte Tests Fehlalarme erzeugen oder Probleme falsch bewerten.</p>
<p>Daher sollten die Ergebnisse dieser Tools kritisch geprüft und immer mit einer manuellen Bewertung ergänzt werden. Nur durch eine Kombination aus automatisierter und manueller Prüfung – kann sichergestellt werden, dass digitale Angebote tatsächlich barrierefrei sind.</p>
<p>Automatisierte Tools sind ein hilfreicher erster Schritt, aber keine alleinige Lösung für eine umfassende Barrierefreiheitsprüfung.</p>
<p>Siehe auch: <a href="/bfit-leitfaeden/5.0/technik/actrules.html#" data-pdf-page="act-rules-accessibility-conformance-testing-rules" data-pdf-anchor="" data-pdf-level="2">ACT Rules: Accessibility Conformance Testing Rules</a></p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-wave-web-accessibility-evaluation-tool">WAVE (Web Accessibility Evaluation Tool)</h4>
<p>WAVE identifiziert potenzielle Zugänglichkeitsprobleme auf Webseiten und bietet visuelle Rückmeldungen direkt auf der Seite. Nutzende können entweder die Online-Version nutzen, indem sie die URL der zu prüfende Seite eingeben oder die Browser-Erweiterungen für Chrome, Firefox und Edge installieren, um lokale oder passwortgeschützte Seiten zu analysieren.</p>
<p><strong>Unter diesem Link downloadbar</strong>: <a href="https://wave.webaim.org/help">wave.webaim.org</a> </p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-arc-toolkit">ARC Toolkit</h4>
<p>Das ARC Toolkit ist ein professionelles Tool zur Barrierefreiheitsprüfung, das als Browser-Erweiterung für Chrome und Firefox verfügbar ist. Es ermöglicht Entwicklern, einzelne Webseiten schnell auf Konformität mit den WCAG 2.1 Level A und AA-Richtlinien zu überprüfen. Das Toolkit bietet detaillierte Einblicke in die Quellcode-Ebene und liefert Empfehlungen zur Behebung identifizierter Barrieren. Zu den Hauptfunktionen gehören die schnelle Analyse einzelner Seiten, die Identifizierung von Farbkontrastproblemen und die Visualisierung der Tabulatorreihenfolge zur Nachbildung der Nutzungserfahrung.</p>
<p><strong>Unter diesem Link downloadbar</strong>: <a href="https://www.tpgi.com/arc-platform/arc-toolkit/">tpgi.com</a> </p>
<h4 id="werkzeuge-zur-überprüfung-der-digitalen-barrierefreiheit-lighthouse">Lighthouse</h4>
<p>Lighthouse ist ein Open-Source-Tool von Google, integriert in die Chrome-Entwicklertools, das die Leistung, Zugänglichkeit und SEO von Webseiten analysiert. Es führt automatisierte Audits durch und generiert Berichte mit Verbesserungsvorschlägen. Entwickler können Lighthouse verwenden, um die Gesamtqualität ihrer Webseiten zu bewerten und spezifische Bereiche zu identifizieren, die optimiert werden müssen. Obwohl es einen allgemeinen Überblick bietet, sollte beachtet werden, dass die von Lighthouse bereitgestellten Zugänglichkeitsbewertungen nicht alle potenziellen Barrieren abdecken und weitere Tests erforderlich sein können.</p>
<p><strong>Unter diesem Link downloadbar</strong>: <a href="https://ionic.io/docs/accessibility/tools">ionic.io</a> </p>
<p>All diese Tools sind wertvolle Hilfsmittel, um die Barrierefreiheit von Webseiten zu evaluieren und zu verbessern. Sie bieten Empfehlungen zur Optimierung, was zu einer inklusiveren Web-Erfahrung für alle Nutzenden führt.</p>
<h2 id="act-rules-accessibility-conformance-testing-rules">ACT Rules: Accessibility Conformance Testing Rules</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/actrules.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_act_rules.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../actrules/actrules.png" style="" alt="" />
<h3 id="act-rules-accessibility-conformance-testing-rules-möglichkeiten-und-grenzen-von-automatisierten-tests">Möglichkeiten und Grenzen von automatisierten Tests</h3>
<p>Immer wieder besteht der Wunsch, Webauftritte oder Teile davon automatisiert zu testen, um möglichst schnell Rückmeldung zur digitalen Barrierefreiheit zu erhalten. In diesem Guide zeigen wir, welche Automatisierungen sinnvoll sind, worauf Ihr bei deren Einsatz achten müsst, und welche Grenzen es aktuell gibt. Als Grundlage nutzen wir die vom W3C verabschiedeten ACT Rules.
KI-gestützte Testansätze sind hier nicht Teil des Betrachtungsrahmens.</p>
<h3 id="act-rules-accessibility-conformance-testing-rules-was-sind-act-rules">Was sind ACT Rules?</h3>
<p>Die ACT Rules (Accessibility Conformance Testing Rules) sind strukturierte Regeln, mit denen Teile von WCAG-Erfolgskriterien automatisiert geprüft werden können. Einige Aspekte eines Kriteriums lassen sich testen, andere jedoch nur manuell prüfen. Ziele sind Reproduzierbarkeit und Vergleichbarkeit von Testergebnissen.</p>
<p>Die Regeln wurden von Expertinnen und Experten diskutiert und formell verabschiedet. Aktuell existieren 32 verabschiedete ACT Rules, mit denen etwa 16 der 50 A- und AA-Erfolgskriterien der WCAG 2.1 teilweise automatisiert geprüft werden können. Zudem liegen 36 vorgeschlagene Regeln vor, die sich noch in Diskussion befinden. Wichtig: ACT Rules sind informativ und kein verbindlicher Standard. Ein gemeldeter Fehler durch eine ACT Rule gilt allerdings als Hinweis auf einen Verstoß gegen das entsprechende Erfolgskriterium.</p>
<h4 id="act-rules-accessibility-conformance-testing-rules-beispiel">Beispiel</h4>
<p>Es lässt sich automatisiert prüfen, ob ein Element ein beschriftendes Label besitzt. Nicht testbar ist, ob die Beschriftung inhaltlich passend ist. Ebenso kann eine Regel prüfen, ob lang-Attribute gesetzt sind, aber nicht, ob das Attribut sprachlich korrekt ist oder ob wechselnde Sprachabschnitte korrekt markiert sind.</p>
<h3 id="act-rules-accessibility-conformance-testing-rules-was-bringen-die-testergebnisse">Was bringen die Testergebnisse?</h3>
<ul>
<li><p>Schneller Überblick: Sie liefern Fachkundigen eine erste Einschätzung der Barrierefreiheit einzelner Seiten.</p></li>
<li><p>Fehlende Sicherheit: Automatisierte Tests können nur einen Teil der Barrierefreiheitsanforderungen abdecken. Die Ergebnisse müssen manuell bestätigt werden.</p></li>
<li><p>Priorisierung: Sie helfen, Problemstellen schnell zu identifizieren und priorisiert zu bearbeiten.</p></li>
<li><p>Grenzen erkennen: Funktionen wie Sprachverständlichkeit, Kontext oder inhaltliche Angemessenheit lassen sich nicht automatisch testen.</p></li>
</ul>
<h3 id="act-rules-accessibility-conformance-testing-rules-wie-kann-ich-act-rules-nutzen">Wie kann ich ACT Rules nutzen?</h3>
<p>Viele bekannte Browser-Plugins für Barrierefreiheit basieren auf den ACT Rules und eignen sich, um einzelne Seiten gezielt zu prüfen. Einige dieser Tools sind kostenfrei nutzbar, andere als kostenpflichtige Versionen mit erweiterten Funktionen verfügbar. Unterschiede zeigen sich unter anderem in der Darstellung der Ergebnisse, in der Aussagekraft der Diagnosen und in der Tiefe der Analyse.
Darüber hinaus können mit ACT Rules eigene Automatisierungslösungen entwickelt und in Entwicklungs-Workflows eingebunden werden.
Manche Plugins visualisieren zusätzlich Überschriftenhierarchien oder markieren Inkonsistenzen – auch wenn dafür aktuell keine offizielle ACT Rule existiert. Solche Darstellungen sind dennoch hilfreich, um strukturelle Schwachstellen schnell sichtbar zu machen.
Viele Browser-Plugins und Barrierefreiheitstools nutzen ACT Rules als Prüfgrundlage.</p>
<h4 id="act-rules-accessibility-conformance-testing-rules-einige-beispiele">Einige Beispiele:</h4>
<ul>
<li><p><a href="https://www.tpgi.com/arc-platform/">ARC-Toolkit:</a> Ein professionelles Page-Level-Testwerkzeug, das WCAG-Konformitätsprobleme sichtbar macht und zum Erkunden von Elementfehlern einlädt.</p></li>
<li><p><a href="https://www.deque.com/blog/axe-core-4-5-first-wcag-2-2-support-and-more/">axe-core:</a> Eine weit verbreitete Testbibliothek, die ihre Regeln zunehmend auf ACT Rule-Strukturen abstimmt.</p></li>
<li><p><a href="https://silktide.com/toolbar/">Silktide Accessibility Checker:</a> Ein browserbasiertes Tool, das zahlreiche WCAG-Prüfungen direkt anzeigt.</p></li>
<li><p><a href="https://www.accessibilitychecker.org/">AccessibilityChecker.org:</a> Frei nutzbarer Webdienst zur Überprüfung von WCAG-Konformität.</p></li>
</ul>
<h4 id="act-rules-accessibility-conformance-testing-rules-umfang-und-grenzen-dieser-tools">Umfang und Grenzen dieser Tools:</h4>
<h5 id="act-rules-accessibility-conformance-testing-rules-vorteile">Vorteile:</h5>
<ul>
<li><p>Automatisierte Prüfung vieler Seitenaspekte.</p></li>
<li><p>Einheitliche Ergebnisse bei gleichen Regeln.</p></li>
<li><p>Schnelle erste Einschätzung.</p></li>
<li><p>Integration in Entwicklungs-Workflows.</p></li>
</ul>
<h5 id="act-rules-accessibility-conformance-testing-rules-grenzen">Grenzen:</h5>
<ul>
<li><p>Tiefgehende manuelle Tests nötig für Vollständigkeit.</p></li>
<li><p>Fehlalarme sind möglich und müssen geprüft werden.</p></li>
<li><p>Unterschiedliche Implementierungen der Tools führen zu Varianz bei Ergebnissen.</p></li>
<li><p>Übernimmt nur prüfbare Teilaspekte von WCAG.</p></li>
</ul>
<h3 id="act-rules-accessibility-conformance-testing-rules-wann-ist-es-sinnvoll-tools-auf-act-rules-basis-zu-verwenden">Wann ist es sinnvoll Tools auf ACT Rules-Basis zu verwenden?</h3>
<p>Wenn ihr bereits Fachwissen in digitaler Barrierefreiheit und Webentwicklung habt, sind Tools auf ACT Rules-Basis ein sinnvolles Mittel, um Teilprüfungen automatisiert durchzuführen</p>
<p>Dabei ist stets wichtig:</p>
<ul>
<li><p>Die Testergebnisse müssen interpretiert und validiert werden.</p></li>
<li><p>Nicht jeder Fehler aus dem Tool ist in allen Fällen ein echter Verstoß.</p></li>
<li><p>Nur mit Erfahrung lassen sich Fehlalarme und echte Problembereiche richtig unterscheiden.</p></li>
</ul>
<p>Automatisierte Tests auf Basis von ACT Rules können nützliche Hinweise liefern, vor allem für einzelne Seiten. Sie helfen beim schnellen Überblick und lassen gezielte Nachprüfungen erkennen. Eine endgültige Bewertung kann jedoch nur gemeinsam mit manuellen Prüfungen und auf Grundlage von Erfahrungswissen erfolgen.</p>
<h3 id="act-rules-accessibility-conformance-testing-rules-weiterführende-informationen">Weiterführende Informationen</h3>
<p>Eine Liste mit allen verabschiedeten und vorgeschlagenen Testregeln findet sich auf folgender Seite:</p>
<ul>
<li><p><a href="https://www.w3.org/WAI/standards-guidelines/act/rules/">All ACT Rules | | WAI | W3C</a></p></li>
<li><p><a href="https://www.tpgi.com/arc-platform/">ARC-Toolkit</a></p></li>
<li><p><a href="https://www.deque.com/blog/axe-core-4-5-first-wcag-2-2-support-and-more/">axe-core</a></p></li>
<li><p><a href="https://silktide.com/toolbar/">Silktide Accessibility Checker</a></p></li>
<li><p><a href="https://www.accessibilitychecker.org/">AccessibilityChecker.org</a></p></li>
</ul>
<h2 id="barrierefreie-formulare">Barrierefreie Formulare</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/barrierefreieformulare.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_barrierefreie_formulare.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../formulare/formulre.png" style="" alt="" />
<p>Ob Kontaktformular, Anmeldung oder Online-Antrag: Formulare sind im Web allgegenwärtig und müssen so gestaltet sein, dass niemand ausgeschlossen wird. Barrierefreie Formulare zeichnen sich durch klare Beschriftungen, nachvollziehbare Struktur und zugängliche Interaktionen aus. Das bedeutet zum Beispiel, dass alle Felder korrekt benannt und per Tastatur erreichbar sind und Rückmeldungen wie Fehlermeldungen verständlich präsentiert werden. So wird sichergestellt, dass wirklich jeder das Formular ausfüllen und absenden kann.</p>
<p>In diesem Guide wird hauptsächlich über HTML-Formulare gesprochen, doch lassen sich gewisse Aspekte auch auf Formulare in anderen Formaten beziehen.</p>
<h3 id="barrierefreie-formulare-warum-sind-barrierefreie-formulare-wichtig">Warum sind barrierefreie Formulare wichtig?</h3>
<p>Gut gestaltete Formulare kommen vielen zugute, aber besonders profitieren Menschen mit Beeinträchtigungen.</p>
<p>Zum Beispiel sind klare Beschriftungen und Hinweise essenziell für blinde und sehbehinderte Personen, die Screenreader nutzen. Ohne korrekte Labels können Screenreader nicht ausgeben, was in ein Feld einzugeben ist.</p>
<p>Auch Personen mit motorischen Beeinträchtigungen oder jene, die keine Maus verwenden, sind auf eine durchdachte Tastaturbedienung angewiesen. Wenn interaktive Elemente nicht per Tastatur erreichbar sind oder der Fokus nicht sichtbar ist, entsteht für diese Nutzenden eine unüberwindbare Hürde.</p>
<p>Menschen mit kognitiven Beeinträchtigungen profitieren von verständlicher Sprache, klaren Anleitungen und vorhersehbaren Abläufen, zum Beispiel helfen ihnen konkrete Fehlermeldungen und Beispieleingaben dabei, Eingabefehler zu vermeiden und zu korrigieren.</p>
<p>Barrierefreie Formulare fördern Inklusion und verbessern für viele die User Experience.</p>
<h3 id="barrierefreie-formulare-relevante-wcag-erfolgskriterien">Relevante WCAG-Erfolgskriterien</h3>
<p>Die Web Content Accessibility Guidelines (WCAG) definieren verschiedene Erfolgskriterien, die für barrierefreie Formulare besonders wichtig sind:</p>
<ul>
<li><p><strong>1.3.1 Informationen und Beziehungen (Level A)</strong>: Alle Informationen und strukturellen Beziehungen müssen programmatisch erkennbar sein.</p></li>
<li><p><strong>2.1.1 Tastatur (Level A)</strong>: Alle Funktionen im Formular müssen mit der Tastatur nutzbar sein.</p></li>
<li><p><strong>2.4.3 Fokusreihenfolge (Level A)</strong>: Die Tab-Reihenfolge beim Durchlaufen des Formulars mit der Tastatur muss logisch und nachvollziehbar sein.</p></li>
<li><p><strong>2.4.7 Sichtbarer Fokus (Level AA)</strong>: Wenn sich ein Element im Fokus befindet, muss dies klar erkennbar sein.</p></li>
<li><p><strong>3.3.1 Fehlererkennung (Level A)</strong>: Wenn ein Fehler bei der Eingabe erkannt wird, muss dies dem Nutzenden eindeutig mitgeteilt werden.</p></li>
<li><p><strong>3.3.2 Beschriftungen oder Anleitungen (Level A)</strong>: Jedes Formularfeld muss eine eindeutige und verständliche Beschriftung oder Anleitung haben.</p></li>
<li><p><strong>3.3.3 Fehlerhilfe (Level AA)</strong>: Es müssen konkrete Hinweise gegeben werden, wie ein Eingabefehler korrigiert werden kann.</p></li>
<li><p><strong>3.3.4 Fehlervermeidung (Level AA)</strong>: Bei kritischen Formularen (z. B. rechtlich verbindlichen Vorgängen) soll die Möglichkeit bestehen, Eingaben zu überprüfen, zu ändern oder den Vorgang abzubrechen</p></li>
</ul>
<h3 id="barrierefreie-formulare-wichtige-aspekte-bei-der-umsetzung">Wichtige Aspekte bei der Umsetzung</h3>
<h4 id="barrierefreie-formulare-aussagekräftige-beschriftungen-und-anleitungen">Aussagekräftige Beschriftungen und Anleitungen</h4>
<ul>
<li><p>Jedes Formularfeld braucht eine sichtbare Text-Beschriftung oder eine klare Anleitung. In HTML erreicht man das durch das label-Element, das mit dem Eingabefeld verknüpft wird.</p></li>
<li><p><strong>Wichtig</strong>: Platzhaltertexte im Eingabefeld (sog. <em>Placeholder</em>) reichen nicht aus und dürfen nicht als alleinige Beschriftung dienen. Sie verschwinden beim Tippen und sind für Screenreader oft nicht zugänglich. Besser ist es, neben jeder Eingabe ein dauerhaft sichtbares Label anzuzeigen. Gegebenenfalls kann man zusätzliche Hinweise unter dem Feld platzieren, um z. B. das erwartete Format zu erläutern („TT.MM.JJJJ“ bei einem Datumsfeld). Sprechende Beschriftungen wie „Telefonnummer (optional)“ machen sofort klar, welche Eingabe erwartet wird und ob ein Feld Pflicht oder freiwillig ist.</p></li>
</ul>
<h4 id="barrierefreie-formulare-tastaturbedienbarkeit-und-fokusführung">Tastaturbedienbarkeit und Fokusführung</h4>
<ul>
<li><p>Ein barrierefreies Formular muss vollständig ohne Maus bedienbar sein. Das bedeutet, dass alle interaktiven Elemente wie z. B. Felder, Buttons und Links mit der Tabulator-Taste erreichbar sind. Die Tab-Reihenfolge sollte der visuellen Anordnung entsprechen.</p></li>
<li><p>Weiterhin muss der Fokus deutlich sichtbar sein. Verwendet CSS, um den Fokuszustand hervorzuheben (z. B. durch einen klaren Rahmen oder Hintergrundfarbe). Vermeiden Sie es, den Standardfokus einfach zu entfernen, ohne Ersatz anzubieten. Gute Fokusmarkierungen helfen Nutzenden mit Sehbehinderung oder Aufmerksamkeitsproblemen, sich im Formular zu orientieren.</p></li>
</ul>
<h4 id="barrierefreie-formulare-fehlermeldungen-und-validierung">Fehlermeldungen und Validierung</h4>
<ul>
<li><p>Eine häufige Barriere sind unklare oder nicht wahrnehmbare Fehlermeldungen. Stellen Sie sicher, dass Fehler sowohl visuell als auch programmatisch ermittelt werden. Konkret heißt das: Falls eine Eingabe fehlt oder ungültig ist, sollte neben dem betreffenden Feld eine gut verständliche Fehlermeldung erscheinen und diese Meldung idealerweise mit dem Feld verknüpft sein (in HTML z. B. via aria-describedby). So liest ein Screenreader die Fehlermeldung vor, sobald das Feld fokussiert wird.</p></li>
<li><p>Die Fehlermeldung selbst sollte präzise formuliert sein: Statt nur „Ungültige Eingabe“ lieber einen konkreten Hinweis geben, etwa „Bitte geben Sie eine fünfstellige Postleitzahl ein“ Das hilft allen Nutzenden, den Fehler zu verstehen. Zeigen Sie Fehler am besten dynamisch an, also sofort bei oder nach der Eingabe, und nicht erst nach dem Absenden des gesamten Formulars. So können Fehler schneller korrigiert werden.</p></li>
<li><p>Ebenfalls empfehlenswert: Nach dem Absenden sollte das Formular eine eindeutige Bestätigung anzeigen (z. B. „Vielen Dank, Ihre Nachricht wurde gesendet.“), damit auch Nutzende von Screenreadern oder mit kognitiven Einschränkungen sicher wissen, dass der Vorgang abgeschlossen ist.</p></li>
</ul>
<h3 id="barrierefreie-formulare-wie-sehen-barrierefreie-formulare-in-der-praxis-aus">Wie sehen barrierefreie Formulare in der Praxis aus?</h3>
<p>Bereits im Markup sind alle Eingabefelder mit ihren Labels verknüpft, Pflichtfelder sind deutlich markiert (etwa durch „(Pflichtfeld)“ im Label) und required Attribut sind gesetzt. Die Absende-Schaltfläche hat einen aussagekräftigen Text wie „Nachricht senden“ statt nur „Abschicken“.</p>
<p>Wird das Formular abgeschickt und es treten Fehler auf, so erscheinen direkt über dem Formular eine verständliche Fehler-Zusammenfassung und an jedem fehlerhaften Feld eine spezifische Fehlermeldung. Beide Hinweise sind mit den jeweiligen Feldern verknüpft, sodass Screenreader-Nutzende diese zugeordnet wahrnehmen können.</p>
<p>Der Tastaturfokus springt nach dem Absenden automatisch zum ersten Fehlerhinweis, damit niemand diesen übersieht. Bei einer Gruppe von Auswahlmöglichkeiten werden in HTML ein <code><fieldset></code> und <code><legend</code>>` genutzt, um diese Optionen als zusammengehörig zu strukturieren.</p>
<h4 id="barrierefreie-formulare-beispiel">Beispiel</h4>
<p>(nach Absenden des Formulars mit Fehlern)</p>
<pre tabindex="0"><code><form aria-labelledby="form-title" novalidate>
<h2 id="form-title">Kontaktformular</h2>
<!-- Fehler-Zusammenfassung -->
<div id="error-summary" role="alert" tabindex="-1">
<p>Bitte beheben Sie die folgenden Fehler:</p>
<ul>
<li>
<a href="#anrede-herr">Bitte wählen Sie eine Anrede aus.</a>
</li>
<li>
<a href="#name">Name ist ein Pflichtfeld.</a>
</li>
<li>
<a href="#email">Bitte geben Sie eine gültige E-Mail-Adresse (Format: team@team.de) ein.</a>
</li>
</ul>
</div>
<!-- Pflichtfeld-Hinweis nur visuell -->
<p aria-hidden="true"><strong>Hinweis:</strong> Felder mit <span>*</span> sind Pflichtfelder.</p>
<!-- Anrede als Gruppenfeld -->
<fieldset aria-describedby="error-anrede">
<legend>Anrede <span aria-hidden="true">*</span></legend>
<label>
<input type="radio" name="anrede" id="anrede-herr" value="herr" required autocomplete="honorific-prefix"> Herr
</label>
<label>
<input type="radio" name="anrede" id="anrede-frau" value="frau" autocomplete="honorific-prefix"> Frau
</label>
<p id="error-anrede" class="error" role="alert">Bitte wählen Sie eine Anrede aus.</p>
</fieldset>
<!-- Name -->
<label for="name">Name <span aria-hidden="true">*</span></label>
<input id="name" name="name" type="text" required autocomplete="name" aria-describedby="error-name">
<p id="error-name" class="error" role="alert">Bitte geben Sie Ihren Namen an.</p>[CH15.1]
<!-- E-Mail -->
<label for="email">E-Mail <span aria-hidden="true">*</span></label>
<input id="email" name="email" type="email" required autocomplete="email" aria-describedby="error-email">
<p id="error-email" class="error" role="alert">Bitte geben Sie eine gültige E-Mail-Adresse (Format: team@team.de) ein.</p>
<!-- Absenden -->
<button type="submit">Nachricht senden</button>
</form>
</code></pre><h3 id="barrierefreie-formulare-drittanbieter-tools">Drittanbieter-Tools</h3>
<p>Oft greifen Redakteure auf Online-Formulardienste wie Google Forms oder Microsoft Forms zurück. Die gute Nachricht: Viele dieser Tools berücksichtigen grundlegende Barrierefreiheitsaspekte bereits von Haus aus.</p>
<p>Google Forms zum Beispiel erstellt Formulare, die für eine breite Zielgruppe nutzbar sind, einschließlich Menschen mit Screenreader oder andere assistive Technologien.</p>
<p>Auch Microsoft Forms bietet Unterstützung für Tastaturnavigation und Screenreader. Microsoft stellt sogar Anleitungen bereit, wie man ihre Formulare mit Screenreader bedient.</p>
<p>Dennoch ist Vorsicht geboten: Die Verantwortung für verständliche Texte, klare Eingabeaufforderungen und barrierefreie Inhalte liegt weiterhin bei den Erstellenden. Achten Sie also auch bei Google/Microsoft Forms darauf, verständliche Feldbeschriftungen zu verwenden, alle notwendigen Hinweise bereitzustellen und Medien (Bilder, Videos) mit Alternativtext bzw. Untertiteln zu versehen. Testen Sie das fertige Formular unbedingt selbst mit der Tastatur und, falls möglich, mit einem Screenreader, um sicherzugehen, dass alles funktioniert. Beachten Sie auch, dass die Ergebnisse solcher Tools (z. B. Auswertungsdiagramme oder Tabellen) unter Umständen nicht vollständig barrierefrei dargestellt werden. Hier kann es sinnvoll sein, alternative Darstellungen oder Exportmöglichkeiten (CSV/Excel) anzubieten.</p>
<h3 id="barrierefreie-formulare-html-formulare-vs-pdf-formulare">HTML-Formulare vs. PDF-Formulare</h3>
<p>Formulare können nicht nur als HTML auf Webseiten, sondern auch in PDF-Dokumenten realisiert werden. Allerdings gibt es wichtige Unterschiede in Bezug auf Barrierefreiheit: HTML-Formulare sind in der Regel flexibler und mit weniger Aufwand barrierefrei zu gestalten.</p>
<p>Durch native HTML-Strukturen und Webstandards lassen sich viele Anforderungen (Beschriftungen, Fokus-Reihenfolge, Fehlermeldungen) relativ einfach umsetzen. Moderne Browser und assistive Technologien unterstützen HTML-Formulare sehr gut, wenn sie korrekt aufgebaut sind.</p>
<p>PDF-Formulare dagegen erfordern spezielle Schritte und Tools, um barrierefrei zu sein. Es gibt derzeit keine kostenfreie Software, um vollständig barrierefreie PDF-Formulare zu erstellen. Der Aufwand ist deutlich höher. PDF-Formulare eignen sich vor allem, wenn das ausgefüllte Dokument unterschrieben oder heruntergeladen werden muss, z. B. bei offiziellen Anträgen oder Verträgen. Doch sollten hier Papierformulare nicht 1 zu 1 ins Digitale umgebaut werden, da diese meist nicht gut dafür konzeptioniert sind. Hier macht sich ein neuer Aufbau des Formulars meist besser.</p>
<p>Für interaktive Umfragen, Feedback-Formulare oder allgemeine Web-Formulare sind hingegen HTML-Lösungen oder spezialisierte Online-Tools besser geeignet. Wir empfehlen daher HTML-Formulare, weil sie mit Standardtechnologien breiter zugänglich sind.</p>
<h3 id="barrierefreie-formulare-checkliste-für-die-erstellung-eines-barrierefreien-formulars">Checkliste für die Erstellung eines barrierefreien Formulars</h3>
<ul>
<li><p><strong>HTML-Standardelemente werden verwendet</strong>: Semantik und Funktion sind klar erkennbar.</p></li>
<li><p><strong>Labels sichtbar und korrekt verknüpft</strong>: Jedes Eingabefeld besitzt ein sichtbares Label, das korrekt mit dem Feld verbunden ist.</p></li>
<li><p><strong>Gruppierungen richtig strukturiert</strong>: Zusammengehörige Felder sind mit <code> <fieldset></code> und <code> <legend></code> gegliedert.</p></li>
<li><p><strong>Hilfetexte sind verbunden</strong>: Zusätzliche Hinweise oder Formatangaben sind mit dem jeweiligen Feld verknüpft.</p></li>
<li><p><strong>Vollständige Tastaturbedienbarkeit</strong>: Das gesamte Formular ist ohne Maus vollständig nutzbar.</p></li>
<li><p><strong>Fehlermeldungen dynamisch und zugänglich</strong>: Fehlermeldungen erscheinen automatisch nach Absenden oder Verlassen des Feldes.</p></li>
<li><p><strong>Formular selbst testen</strong>:
</p><ul>
<li><p>Tastaturnavigation prüfen: Sind alle interaktiven Elemente bedienbar?</p></li>
<li><p>Screenreader-Test durchführen: Werden alle Informationen übermittelt?</p></li>
<li><p>Responsives Verhalten prüfen: Sind alle Inhalte in der mobilen Ansicht sichtbar und bedienbar?</p></li>
</ul>
</li>
</ul>
<h2 id="captchas-und-digitale-barrierefreiheit">CAPTCHAs und digitale Barrierefreiheit</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/capchas.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/capchas_und_digitale_barrierefreiheit.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../capchas/image1.png" style="" alt="Abgebildet ist ein Roboter im Anzug. Rechts neben ihm befindet sich ein „I’m not a robot“-CAPTCHA, das erfolgreich gelöst wurde." />
<h3 id="captchas-und-digitale-barrierefreiheit-was-ist-ein-captcha">Was ist ein CAPTCHA?</h3>
<p>Ein CAPTCHA ist eine kleine Aufgabe auf einer Webseite, mit der überprüft werden soll, ob ein Mensch oder ein Bot die Seite nutzt. Die Abkürzung steht für <span lang="en">„<strong>C</strong>ompletely <strong>A</strong>utomated <strong>P</strong>ublic <strong>T</strong>uring test to tell <strong>C</strong>omputers and <strong>H</strong>umans <strong>A</strong>part“</span>.</p>
<p>Der Name beschreibt damit bereits das Ziel: automatisierte Angriffe durch Bots abwehren, ohne echten Nutzenden den Zugang zu Webseiten zu erschweren. Denn Bots können erheblichen Schaden anrichten: Sie erstellen massenhaft Fake-Profile, testen gestohlene Passwörter auf Login-Seiten oder durchsuchen Webseiten nach Daten wie E-Mail-Adressen, um diese für automatisierte Angriffe weiterzuverwenden oder zu verkaufen.</p>
<p>Gleichzeitig sollen echte menschliche Nutzende barrierefrei auf Inhalte und Funktionen im Internet zugreifen können, unabhängig von individuellen Fähigkeiten oder genutzten Hilfsmitteln. Doch genau das gelingt in der Praxis oft nicht. Viele CAPTCHA-Lösungen sind für Menschen mit Beeinträchtigungen schwer oder gar nicht zugänglich.</p>
<p>In diesem Guide zeigen wir euch daher, welche CAPTCHA-Arten es gibt und welche Barrieren sie erzeugen können. Ziel ist es, ein besseres Verständnis für bestehende Möglichkeiten zu schaffen und praktische Hinweise für die Gestaltung digitaler Angebote zu geben.</p>
<h3 id="captchas-und-digitale-barrierefreiheit-sicherheit-und-barrierefreiheit-ein-widerspruch">Sicherheit und Barrierefreiheit: Ein Widerspruch?</h3>
<p>Um Webseiten vor automatisierten Angriffen zu schützen, wurde Ende der 1990er Jahre eine erste CAPTCHA-Lösung entwickelt: verzerrte Buchstaben- und Zahlenkombinationen. Diese später als reCAPTCHA v1 bekannte Methode galt zunächst als elegante Lösung: Man nahm an, dass Menschen die Zeichen trotz Verformung lesen und fehlerfrei abtippen können, während Maschinen an der Aufgabe scheitern. In der Praxis jedoch zeigte sich schnell, dass viele Menschen große Schwierigkeiten mit dieser Art von Test hatten. Für Personen mit Sehbehinderungen oder Dyslexie sind Text-CAPTCHAs nicht zugänglich. Auch assistive Technologien wie Screenreader können die verzerrten Zeichen nicht erfassen.</p>
<figure>
<img src="../capchas/image2.png" style="" alt="Text-CAPTCHA mit der Aufgabe: "Tippen Sie die Buchstaben aus dem Bild ab." Gezeigt werden die Umrisse von Buchstaben und Zahlen, die von Linien gekreuzt werden und so schwer zu erkennen sind." />
<figcaption>Abbildung 1: Text-CAPTCHA</figcaption>
</figure>
<p>Um diese Barrieren zu adressieren, wurden Audio-CAPTCHAs eingeführt. Nutzende hören dabei eine Reihe von Zahlen oder Wörtern mit Störgeräuschen und sollen diese korrekt wiedergeben. Doch auch diese Variante bringt neue Hürden mit sich: Für Menschen mit Hörbeeinträchtigungen, auditiven Verarbeitungsstörungen oder kognitiven Einschränkungen sind die Aufnahmen schwer oder gar nicht verständlich.</p>
<figure>
<img src="../capchas/image4.svg" style="" alt="Audio-CAPTCHA mit der Aufgabe: "Tippen Sie die Buchstaben ein, die Sie gehört haben". Eine zugehörige Audiodatei kann über "Audio anhören" abgespielt werden." />
<figcaption>Abbildung 2: Audio-CAPTCHA</figcaption>
</figure>
<p>Als nächste Evolutionsstufe folgten bildbasierte CAPTCHAs, bei denen Objekte in Fotos erkannt und ausgewählt werden müssen, z. B. alle Felder mit Ampeln oder Fahrrädern. Diese Methode setzt gutes Sehen und räumliches Erkennen voraus. Seheingeschränkte oder blinde Menschen können diese Tests kaum eigenständig lösen und empfinden diese häufig als frustrierend.</p>
<figure>
<img src="../capchas/image5.png" style="" alt="Bild-CAPTCHA mit der Aufgabe: "Wählen Sie alle Felder mit Straßenschildern aus." Abgebildet ist ein Foto einer Straße, das in Quadrate aufgeteilt wurde. " />
<figcaption><p>Abbildung 3: Bild-CAPTCHA</p></figcaption>
</figure>
<p>Auch mathematische Aufgaben wurden getestet, um Menschen und Bots zu unterscheiden. Fragen wie „Was ist 74 minus 36?“ setzen jedoch Zahlenverständnis, Konzentration und sprachliches Erfassen voraus. Für Menschen mit Dyskalkulie, Aufmerksamkeitsstörungen oder kognitiven Einschränkungen kann das zur unüberwindbaren Hürde werden.</p>
<figure>
<img src="../capchas/image6.png" style="" alt="Mathematisches CAPTCHA mit der Aufgabe: "Lösen Sie die Rechenaufgabe!" Gezeigt wird ein Bild, auf dem "21 + 42 = ?" zu lesen ist." />
<figcaption><p>Abbildung 4: Mathematisches CAPTCHA</p></figcaption>
</figure>
<p>Weniger verbreitet, aber ebenfalls genutzt, sind Logikrätsel oder Trivia-Fragen wie „Welche Zahl gehört nicht in die Reihe?“ oder „Wer war der erste Mensch auf dem Mond?“. Solche Aufgaben setzen abstraktes Denken, kulturelles Wissen und gute Lesefähigkeit voraus. Diese Anforderungen schließen beispielsweise Personen mit Lernschwierigkeiten, niedrigem Bildungsgrad oder geringen Deutschkenntnissen aus.</p>
<figure>
<img src="../capchas/image7.png" style="" alt="Logikrätsel als CAPTCHA mit der Aufgabe: "Drehen Sie den Gegenstand in die korrekte Position". Gezeigt wird ein Tier, das auf dem Kopf steht und mit Pfeilen rotiert werden kann." />
<figcaption><p>Abbildung 5: Logikrätsel als CAPTCHA</p></figcaption>
</figure>
<p>Neuere Systeme wie reCAPTCHA v2 („Ich bin kein Roboter“-Checkbox) oder invisible reCAPTCHA versuchen, Bots durch eine Verhaltensanalyse zu erkennen. Analysiert werden etwa Mausbewegungen oder Tippverhalten. Diese Methoden sind weniger aufdringlich als klassische Rätsel. Doch wer mit der Tastatur statt der Maus navigiert, Hilfsmittel wie Screenreader verwendet oder motorische Einschränkungen hat, verhält sich oft anders als der Durchschnitt. Diese Abweichung können dazu führen, dass Betroffene fälschlicherweise als Bots eingestuft werden und dann doch ein zusätzliches, oft schwer zugängliches CAPTCHA lösen müssen.</p>
<figure>
<img src="../capchas/image8.png" style="" alt="Signalbasiertes CAPTCHA zur Verhaltensanalyse mit der Aufgabe, einen Hacken bei "I'm not a robot" zu setzen." />
<figcaption><p>Abbildung 6: Signalbasiertes CAPTCHA (Verhaltensanalyse)</p></figcaption>
</figure>
<p>Neben den Problemen mit der Barrierefreiheit zeigen sich bei den bereits vorgestellten CAPTCHAs auch deutliche Schwächen bei der Nutzerfreundlichkeit. Unabhängig vom Thema Behinderung benötigen Nutzende meist mehrere Anläufe, um CAPTCHAs zu lösen oder scheitern regelmäßig daran. Besonders ältere Personen oder Menschen mit wenig Erfahrung im Umgang mit digitalen Anwendungen empfinden die Tests oft als verwirrend oder frustrierend.</p>
<p>Hinzu kommt ein weiterer entscheidender Faktor: Bots werden immer besser und somit verlieren CAPTCHAs kontinuierlich an Wirkungen. OCR-Technik knackt verzerrte Texte, Spracherkennung überwindet Audio-CAPTCHAs, moderne KIs erkennen Objekte auf Bildern und verhaltensbasierte CAPTCHAs lassen sich durch simulierte Bewegungen täuschen. Diese Entwicklungen sorgen für einen stetigen Innovationsdruck: CAPTCHA-Systeme müssen sowohl zugänglich für Menschen als auch robust gegen immer ausgefeiltere Bots sein.</p>
<h3 id="captchas-und-digitale-barrierefreiheit-barrierefreie-alternativen-zu-klassischen-captchas">Barrierefreie Alternativen zu klassischen CAPTCHAS</h3>
<p>Um die Barrieren klassischer CAPTCHAs zu vermeiden, wurden in den letzten Jahren alternative Ansätze entwickelt.</p>
<h4 id="captchas-und-digitale-barrierefreiheit-proof-of-work-verfahren-zb-friendly-captcha">Proof-of-Work-Verfahren (z. B. Friendly CAPTCHA)</h4>
<p>Diese Methode verlagert die Sicherheitsprüfung auf den Computer: Im Hintergrund muss der Rechner eine komplizierte Rechenaufgabe lösen. Der Mensch selbst bekommt davon nichts mit. Da Bots mehrere Anfragen gleichzeitig an Webseiten stellen, stoßen sie bei vielen Rechenaufgaben schnell an ihre Grenzen. Diese CAPTCHAs helfen allen, die bei klassischen CAPTCHAs durch unverständliche, visuelle oder akustische Aufgaben benachteiligt sind.</p>
<h4 id="captchas-und-digitale-barrierefreiheit-zeitbasierte-filter">Zeitbasierte Filter</h4>
<p>Diese Technik prüft, wie schnell ein Formular ausgefüllt wird. Bots agieren oft in Millisekunden. Menschen brauchen länger. Ist das Formular verdächtig schnell ausgefüllt, wird der Absender blockiert – ganz ohne zusätzliche Interaktion.</p>
<h4 id="captchas-und-digitale-barrierefreiheit-honeypot-technik">Honeypot-Technik</h4>
<p>Im Formular wird ein zusätzliches Feld eingebaut, das nur Bots sehen, Menschen jedoch nicht. Wird das Feld befüllt, ist die Anfrage verdächtig.</p>
<p>Wichtig: Das Feld darf nicht zu sehen sein und muss für Screenreader unerreichbar sein. Dazu blendet man es mit <code>style="display:none"</code> und <code>aria-hidden=true\"</code> aus.</p>
<h4 id="captchas-und-digitale-barrierefreiheit-proof-of-personhood-systeme">Proof-of-Personhood-Systeme</h4>
<p>Diese Systeme prüfen nicht nur, ob eine Anfrage von einem Menschen kommt, sondern ob es sich um eine individuelle reale Person handelt. Möglich wird das durch kryptografische Verfahren, Gerätediagnosen oder verifizierte Identitäten. Dieser Ansatz steckt noch in der Entwicklung. Langfristig könnten Proof-of-Personhood-Systeme eine benutzerfreundliche Sicherheitslösung für alle sein.</p>
<h3 id="captchas-und-digitale-barrierefreiheit-checkliste">Checkliste</h3>
<p>Damit Sicherheitsmechanismen auf eurer Webseite niemanden ausschließen, solltet ihr folgende Hinweise bei der Umsetzung beachten:</p>
<ul>
<li><p>Verzichtet auf klassische Bild- oder Audio-CAPTCHAs. Wählt stattdessen Verfahren, die ohne Nutzerinteraktion auskommen und passiv im Hintergrund ablaufen.</p></li>
<li><p>Beachtet das Zwei-Sinne-Prinzip. Gebt also niemals visuelle Anweisungen wie „Wählen Sie alle Bilder mit Ampeln“, ohne Alternativen anzubieten.</p></li>
<li><p>Stellt sicher, dass alle Sicherheitslösungen mit assistiven Technologien kompatibel sind. Testet dafür eure Software mit Screenreadern und verschiedenen Eingabemethoden (Tastatur, Sprache etc.).</p></li>
<li><p>Informiert Nutzende über die verwendete Schutzmaßnahme, z. B. mit einem Hinweis wie „Zum Schutz gegen Spam verwenden wir eine barrierefreie Sicherheitsprüfung im Hintergrund.“</p></li>
<li><p>Führt regelmäßige Prüfungen durch, um sicherzustellen, dass neue Sicherheitsmechanismen keine unbeabsichtigten Barrieren einführen.</p></li>
</ul>
<h3 id="captchas-und-digitale-barrierefreiheit-glossar">Glossar</h3>
<ul>
<li><p><strong>Assistive Technologien</strong>: Hilfsmittel wie Screenreader, Braillezeilen oder Sprachausgabe, die Menschen mit Beeinträchtigungen die Nutzung digitaler Inhalte ermöglichen.</p></li>
<li><p><strong>Bot</strong>: Ein Bot ist ein Computerprogramm, das automatisch Aufgaben ausführt, für die sonst Menschen nötig wären. Zum Beispiel Webseiten durchsuchen oder Nachrichten beantworten.</p></li>
<li><p><strong>CAPTCHA</strong>: Kleine Aufgabe auf einer Webseite, mit der überprüft werden soll, ob ein Mensch oder ein Bot die Seite nutzt. Kurz für: Completely Automated Public Turing test to tell Computers and Humans Apart.</p></li>
<li><p><strong>Dyslexie</strong>: Auch „Lese-Rechtschreib-Störung“ genannt. Eine Lernstörung, bei der das Lesen und Schreiben schwerfällt.</p></li>
<li><p><strong>Dyskalkulie</strong>: Auch „Rechenstörung“ genannt. Eine Lernstörung, bei der das Verstehen und Anwenden von Zahlen und Rechenregeln erschwert ist.</p></li>
<li><p><strong>Screenreader</strong>: Ein Programm, das Texte auf dem Bildschirm vorliest oder in Braille ausgibt. Es hilft blinden oder sehbehinderten Menschen, Computer und Webseiten zu nutzen.</p></li>
<li><p><strong>OCR</strong>: Kurz für „Optical Character Recognition“ (optische Zeichenerkennung). Eine Technik, mit der Texte aus Bildern oder gescannten Dokumenten automatisch erkannt und digital lesbar gemacht werden.</p></li>
<li><p><strong>Zwei-Sinne-Prinzip</strong>: Wichtige Informationen sollen immer über mindestens zwei Sinne wahrnehmbar sein, zum Beispiel visuell (sehen) und auditiv (hören).</p></li>
</ul>
<h2 id="skip-links-für-barrierefreie-webseiten">Skip Links für barrierefreie Webseiten</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/skip-links-fuer-barrierefreie-webseiten.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_skiplinks_fuer_barrierefreie_webseiten.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../skiplinks/undraw_ship-it_vn4g.png" style="" alt="" />
<h3 id="skip-links-für-barrierefreie-webseiten-was-sind-skip-links">Was sind Skip Links?</h3>
<p>Skip Links sind Links einer Webseite, die es Nutzenden ermöglichen, repetitive Elemente zu überspringen und effizienter zu navigieren. Dies ist besonders hilfreich für Personen, die assistive Technologien wie Screenreader oder ausschließlich die Tastatur zur Navigation verwenden. Sie ermöglichen eine inklusivere Nutzung von Webauftritten.</p>
<h4 id="skip-links-für-barrierefreie-webseiten-beispiel-für-einen-skip-link">Beispiel für einen Skip Link</h4>
<p>Ein Link ganz oben auf der Seite mit dem Text „Zum Hauptinhalt springen“. Wird dieser aktiviert, landet der Fokus direkt auf dem Hauptinhalt der Seite und überspringt alle Elemente davor.</p>
<img src="../skiplinks/image1.png" style="" alt="Skip Link mit der Bezeichnung: "zum Hauptinhalt springen"" />
<h3 id="skip-links-für-barrierefreie-webseiten-warum-sind-skip-links-wichtig-für-die-digitale-barrierefreiheit">Warum sind Skip Links wichtig für die digitale Barrierefreiheit?</h3>
<p>Es wird sichergestellt, dass Webseiten für alle Menschen gleichermaßen nutzbar sind, unabhängig von ihrer individuellen Fähigkeit zur Interaktion mit digitalen Inhalten. Darüber hinaus sorgen sie für eine bessere Nutzung von Webinhalten, indem sie den direkten Zugang zu wichtigen Informationen ermöglichen, ohne dass Nutzende sich durch viele Strukturelemente kämpfen müssen.</p>
<p>Die Integration von Skip Links ist daher nicht nur eine technische Maßnahme zur Erfüllung von Barrierefreiheitsstandards, sondern eine grundlegende Verbesserung der Benutzerfreundlichkeit für alle. Sie erleichtert das Zurechtfinden auf komplexen Webseiten und stellt sicher, dass alle Inhalte ohne unnötige Hindernisse erreichbar sind. Letztlich sind Skip Links ein einfacher, aber wirkungsvoller Schritt hin zu einer inklusiven digitalen Umgebung.</p>
<h3 id="skip-links-für-barrierefreie-webseiten-welche-nutzergruppen-profitieren-davon">Welche Nutzergruppen profitieren davon?</h3>
<ul>
<li><p><strong>Personen mit Sehbeeinträchtigungen</strong>: Für blinde oder sehbehinderte Menschen, die Screenreader verwenden, erleichtern Skip Links die Navigation erheblich. Ohne diese Funktion müssten sie sich durch jede Navigationsebene arbeiten, bevor sie zum Inhalt gelangen. Skip Links ermöglichen es ihnen, diese wiederkehrenden Elemente zu überspringen und direkt zu den relevanten Informationen zu gelangen.</p></li>
<li><p><strong>Nutzende mit motorischen Beeinträchtigungen</strong>: Personen mit eingeschränkter Bewegungsfähigkeit, die auf Tastaturnavigation angewiesen sind, profitieren von Skip Links, da sie die Anzahl der notwendigen Tastatureingaben reduzieren. Dies erleichtert den Zugang zum Hauptinhalt und minimiert den physischen Aufwand.</p></li>
<li><p><strong>Menschen mit kognitiven Beeinträchtigungen</strong>: Skip Links können auch für Personen mit kognitiven Einschränkungen hilfreich sein, indem sie die Komplexität der Navigation verringern. Durch das Überspringen von sich wiederholenden Navigationsblöcken wird die kognitive Belastung reduziert, was zu einer klareren und verständlicheren Benutzererfahrung führt.</p></li>
</ul>
<h3 id="skip-links-für-barrierefreie-webseiten-relevante-gesetzliche-grundlagen">Relevante gesetzliche Grundlagen</h3>
<p>Für digitale Angebote des Bundes gilt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0). Nach § 3 Abs. 2 BITV 2.0 ist die Europäische Norm EN 301 549 als technischer Standard zu beachten. In Abschnitt 9.2.4.1 der EN 301 549 wird auf das Erfolgskriterium 2.4.1 der Web Content Accessibility Guidelines (WCAG) 2.1 verwiesen. In den Ländern gelten teilweise ähnliche Regelungen. Es wird empfohlen, sich über die vor Ort geltenden gesetzlichen Bestimmungen zu informieren.</p>
<h4 id="skip-links-für-barrierefreie-webseiten-wcag-21-erfolgskriterium-241">WCAG 2.1 Erfolgskriterium 2.4.1</h4>
<p>Das Erfolgskriterium 2.4.1 der Web Content Accessibility Guidelines (WCAG) 2.1 fordert, dass Webseiten einen Mechanismus bereitstellen, der es Nutzenden ermöglicht, wiederkehrende Inhaltsblöcke zu überspringen. Dies ist besonders für Personen wichtig, die Inhalte sequenziell, beispielsweise mit Tastatur oder Screenreader, durchlaufen. Ohne diese Funktion müssten sie auf jeder Seite erneut durch identische Navigationsleisten, Kopfzeilen oder Werbebanner navigieren, bevor sie zum gewünschten Inhalt gelangen.</p>
<h3 id="skip-links-für-barrierefreie-webseiten-praktische-umsetzung-von-skip-links">Praktische Umsetzung von Skip Links</h3>
<p>Bei der Umsetzung von Skip Links sollten folgende Aspekte berücksichtigt werden:</p>
<ul>
<li><p><strong>Platzierung</strong>: Der Skip Link sollte als erstes interaktives Element auf der Seite stehen, damit er sofort per Tastatur erreichbar ist.</p></li>
<li><p><strong>Sichtbarkeit</strong>: Standardmäßig kann der Skip Link verborgen sein, sollte jedoch sichtbar werden, sobald er den Fokus erhält, um Nutzenden seine Existenz und Funktionalität anzuzeigen.</p></li>
<li><p><strong>Beschriftung</strong>: Eine klare und prägnante Beschriftung wie "Zum Hauptinhalt springen" hilft Nutzenden, die Funktion des Links sofort zu verstehen. Das Label der Links sollte dabei auch deutlich machen, dass es sich um Skip Links handelt, um eine eindeutige Orientierung zu gewährleisten.</p></li>
<li><p><strong>Technische Umsetzung</strong>: Die Implementierung sollte sicherstellen, dass der Fokus nach Aktivierung des Skip Links tatsächlich zum definierten Ziel springt, und dies sollte in verschiedenen Browsern und mit unterschiedlichen assistiven Technologien getestet werden.</p></li>
</ul>
<h4 id="skip-links-für-barrierefreie-webseiten-beispiel">Beispiel</h4>
<p>Ein Skip Link am Seitenanfang führt direkt zum Hauptinhalt der Webseite.</p>
<p><code><a href="#maincontent" class="skip-link">Zum Hauptinhalt springen</a></code></p>
<img src="../skiplinks/image2.png" style="" alt="" />
<pre tabindex="0"><code><main id=\"maincontent">
<h1>Willkommen auf unserer Seite</h1>
</main>
</code></pre><img src="../skiplinks/image3.png" style="" alt="" />
<p>Mithilfe von CSS kann der Skip-Link bei Fokussierung sichtbar gemacht werden:</p>
<pre tabindex="0"><code>skip-link {
background-color: \#fff;
position: absolute;
padding: 0.2em;
display: block;
}
skip-link:not( :focus): not(:active) {
clip-path: inset(50%);
height: 1px;
overflow: hidden; white-space: nowrap;
width: 1px;
}
</code></pre><img src="../skiplinks/image4.png" style="" alt="" />
<h3 id="skip-links-für-barrierefreie-webseiten-weitere-informationen">Weitere Informationen</h3>
<ul>
<li><p><a href="https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks">Understanding Success Criterion 2.4.1: Bypass Blocks | WAI | W3C</a></p></li>
<li><p><a href="https://www.w3schools.com/accessibility/accessibility_skip_links.php">Accessibility Skip links</a></p></li>
<li><p><a href="https://webaim.org/techniques/skipnav/">WebAIM: Skip Navigation Links</a></p></li>
</ul>
<h3 id="skip-links-für-barrierefreie-webseiten-checkliste-für-eine-barrierefreie-skip-link-umsetzung">Checkliste für eine barrierefreie Skip Link-Umsetzung</h3>
<ol>
<li><p>Platzierung und Sichtbarkeit:
</p><ul>
<li><p>Ist der Skip Link an oberster Stelle der Seite platziert?</p></li>
<li><p>Wird der Link sichtbar, wenn er fokussiert wird?</p></li>
</ul>
</li>
<li><p>Funktionalität:
</p><ul>
<li><p>Führt der Link zuverlässig zu den Inhalten?</p></li>
<li><p>Ist sichergestellt, dass der Skip Link für alle Nutzenden funktioniert, unabhängig von der Eingabemethode?</p></li>
</ul>
</li>
<li><p>Beschriftung und Nutzerführung:
</p><ul>
<li><p>Sind die Beschriftungen eindeutig und verständlich?</p></li>
<li><p>Wird die Navigation für Nutzende durch den Skip Link tatsächlich erleichtert?</p></li>
</ul>
</li>
<li><p>Technische Umsetzung:
</p><ul>
<li><p>Ist sichergestellt, dass der Skip Link auf allen Geräten und in allen gängigen Browsern korrekt funktioniert?</p></li>
<li><p>Wurde getestet, ob Screenreader den Skip Link korrekt interpretieren?</p></li>
</ul>
</li>
</ol>
<h2 id="tastaturbedienbarkeit">Tastaturbedienbarkeit</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/tastaturbedienung.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_tastaturbedienbarkeit.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../Tastaturbedienung/image2.png" style="" alt="" />
<h3 id="tastaturbedienbarkeit-was-ist-eine-tastaturbedienung">Was ist eine Tastaturbedienung?</h3>
<p>Eine Tastaturbedienung beschreibt die Möglichkeit, eine Webseite ausschließlich mit der Tastatur zu bedienen, ohne Maus oder Touch-Gesten. Durch die Tab-Taste, Pfeiltasten, Enter und Escape können Nutzende durch Inhalte und interaktive Elemente wie Links, Buttons oder Formulare springen und diese bedienen.</p>
<p>Dies ist eine Grundvoraussetzung für digitale Barrierefreiheit, denn viele Menschen sind auf die Navigation per Tastatur angewiesen, sei es dauerhaft oder temporär (z. B. bei einem gebrochenen Arm / Hand).</p>
<h3 id="tastaturbedienbarkeit-warum-ist-tastaturbedienung-wichtig-für-die-digitale-barrierefreiheit">Warum ist Tastaturbedienung wichtig für die digitale Barrierefreiheit?</h3>
<p>Eine durchgängige Tastaturbedienbarkeit stellt sicher, dass digitale Inhalte auch ohne Maus vollständig nutzbar sind. Das betrifft nicht nur blinde Menschen, die mit Screenreader arbeiten, sondern auch Nutzende mit motorischen oder kognitiven Einschränkungen. Ohne eine funktionierende Tastaturbedienung können zentrale Funktionen wie das Ausfüllen eines Formulars oder das Öffnen eines Menüs nicht erreicht werden, die Seite ist dann für viele unzugänglich.</p>
<p>Tastaturbedienbarkeit ist eine zentrale Anforderung in allen wichtigen Regelwerken zur digitalen Barrierefreiheit. Sie ist gesetzlich verpflichtend und betrifft sowohl öffentliche Stellen als auch mit Blick auf das Barrierefreiheitsstärkungsgesetz (BFSG), viele private Anbieter von digitalen Produkten und Dienstleistungen.</p>
<p>Eine Webseite oder Anwendung, die nicht vollständig über die Tastatur nutzbar ist, verstößt gegen grundlegende Anforderungen an die Barrierefreiheit.</p>
<h3 id="tastaturbedienbarkeit-welche-nutzergruppen-profitieren-davon">Welche Nutzergruppen profitieren davon?</h3>
<h4 id="tastaturbedienbarkeit-menschen-mit-sehbeeinträchtigungen">Menschen mit Sehbeeinträchtigungen</h4>
<p>Blinde und stark sehbehinderte Personen können Webseiten nicht visuell erfassen. Sie nutzen assistive Technologien, die Inhalte vorlesen, vergrößern oder über eine Braillezeile ausgeben. Die Navigation erfolgt dabei ausschließlich über die Tastatur, meist mithilfe der Tab-Taste, Pfeiltasten und spezieller Shortcuts.</p>
<p>Fehlt eine saubere Tastaturbedienung, bleiben zentrale Inhalte oder Funktionen für diese Menschen unzugänglich. Besonders wichtig sind dabei eine sinnvolle Fokusreihenfolge (bezeichnet die Reihenfolge, in der interaktive Elemente wie Links, Buttons oder Formulare beim Navigieren mit der Tastatur, typischerweise mit der Tab-Taste angesprungen werden) und eine klare Struktur der Webseite, die Screenreader korrekt interpretieren können.</p>
<h4 id="tastaturbedienbarkeit-personen-mit-motorischen-einschränkungen">Personen mit motorischen Einschränkungen</h4>
<p>Für Menschen mit eingeschränkter Feinmotorik, Muskelkraft oder Koordination (z. B. durch Multiple Sklerose, spastische Lähmungen oder Parkinson) kann das präzise Bedienen einer Maus sehr anstrengend oder gar unmöglich sein. Die Tastaturbedienung bietet ihnen eine zuverlässige, wiederholbare Bedienmöglichkeit. Viele Personen nutzen auch Sondertastaturen oder Eingabehilfen, die auf Tastatursteuerung basieren. Ohne konsequente Tastaturbedienbarkeit bleibt die Nutzung digitaler Angebote für sie stark eingeschränkt.</p>
<h4 id="tastaturbedienbarkeit-nutzende-mit-kognitiven-oder-neurologischen-beeinträchtigungen">Nutzende mit kognitiven oder neurologischen Beeinträchtigungen</h4>
<p>Personen mit Autismus, ADHS oder anderen kognitiven Einschränkungen profitieren von klaren, konsistenten Navigationswegen. Eine gut strukturierte Tastaturbedienung ermöglicht es, sich schrittweise und nachvollziehbar durch Inhalte zu bewegen, ohne Reizüberflutung durch Mausbewegungen oder unerwartete Interaktionen. Auch das Erlernen und Wiederholen von Tastaturabläufen gibt Sicherheit und reduziert die kognitive Belastung.</p>
<h4 id="tastaturbedienbarkeit-menschen-mit-temporären-einschränkungen">Menschen mit temporären Einschränkungen</h4>
<p>Barrierefreiheit betrifft nicht nur Menschen mit dauerhaften Einschränkungen. Auch ein gebrochener Arm, eine Sehnenscheidenentzündung oder ein verstauchter Finger können vorübergehend die Nutzung einer Maus verhindern. In solchen Fällen bietet die Tastaturbedienung eine alternative, schmerzfreie Möglichkeit, um digitale Angebote weiterhin zu nutzen.</p>
<p>Darüber hinaus gibt es viele Alltagssituationen, in denen das Fehlen einer Maus, technische Probleme bei der Mausbedienung oder beengte Platzverhältnisse (etwa beim Arbeiten mit dem Laptop im Zug) die Mausnutzung erschweren oder unmöglich machen. Auch hier bietet eine zuverlässige Tastaturbedienung eine wichtige Alternative.</p>
<h4 id="tastaturbedienbarkeit-power-user-und-technikaffine-personen">Power-User und technikaffine Personen</h4>
<p>Viele erfahrene Nutzende, sogenannte Power-User bevorzugen die Tastatur, weil sie schneller, effizienter und präziser damit arbeiten können. Gerade in professionellen Kontexten sparen Tastenkombinationen und eine durchdachte Tab-Reihenfolge Zeit und Klicks. Eine konsequent umgesetzte Tastaturbedienung steigert so nicht nur die Barrierefreiheit, sondern auch die allgemeine Benutzerfreundlichkeit für alle, die gerne auf Mausbedienung verzichten.</p>
<h3 id="tastaturbedienbarkeit-relevante-wcag-erfolgskriterien-wcag-21">Relevante WCAG-Erfolgskriterien (WCAG 2.1)</h3>
<p>Die WCAG 2.1 bilden international den verbindlichen Maßstab für barrierefreie Gestaltung digitaler Inhalte. Im Bereich der Tastaturbedienbarkeit sind insbesondere folgende Erfolgskriterien relevant:</p>
<h4 id="tastaturbedienbarkeit-erfolgskriterium-211-tastatur-level-a">Erfolgskriterium 2.1.1 Tastatur (Level A)</h4>
<p>Alle Funktionen müssen uneingeschränkt über eine Tastatur bedienbar sein. Dies bedeutet: Nutzende dürfen nicht gezwungen sein, eine Maus oder einen Touchscreen zu verwenden, um Inhalte zu erreichen oder Funktionen auszuführen. Jede Interaktion – ob Link, Button, Formularfeld oder Menü – muss über Tastaturbefehle zugänglich sein.</p>
<h4 id="tastaturbedienbarkeit-erfolgskriterium-212-keine-tastaturfalle-level-a">Erfolgskriterium 2.1.2 Keine Tastaturfalle (Level A)</h4>
<p>Nutzende dürfen durch die Tastatursteuerung nicht in einem Bereich der Seite „gefangen“ bleiben.</p>
<p>Beispielsweise muss der Fokus nach dem Öffnen eines modalen Dialogfensters weiterhin durch Tab oder Escape logisch gesteuert werden können. Eine fehlende oder unvollständige Fokussteuerung führt zu einer sogenannten „Tastaturfalle“, die für viele Nutzende eine vollständige Barriere darstellt.</p>
<h4 id="tastaturbedienbarkeit-erfolgskriterium-243-fokusreihenfolge-level-a">Erfolgskriterium 2.4.3 Fokusreihenfolge (Level A)</h4>
<p>Die Reihenfolge, in der interaktive Elemente per Tab-Taste erreicht werden, muss der visuellen und logischen Struktur der Seite entsprechen.</p>
<p>Dies ist entscheidend für das Verständnis und die intuitive Bedienbarkeit. Eine unlogische oder verwirrende Tab-Reihenfolge erschwert nicht nur Menschen mit Behinderungen die Navigation, sondern auch allen anderen Nutzenden.</p>
<h4 id="tastaturbedienbarkeit-erfolgskriterium-247-sichtbarer-fokus-level-aa">Erfolgskriterium 2.4.7 Sichtbarer Fokus (Level AA)</h4>
<p>Der aktuelle Tastaturfokus muss jederzeit klar und visuell erkennbar sein.</p>
<p>Der Fokusindikator zeigt, welches Element gerade aktiv ist. Er muss kontrastreich genug gestaltet sein, sodass er von Nutzenden – insbesondere von Menschen mit Sehbeeinträchtigungen – zuverlässig wahrgenommen werden kann. Fokus-Markierungen dürfen nicht durch Designanpassungen (z. B. outline: none) entfernt werden.</p>
<h3 id="tastaturbedienbarkeit-häufige-probleme-und-lösungen">Häufige Probleme und Lösungen</h3>
<h4 id="tastaturbedienbarkeit-interaktive-elemente-sind-nicht-per-tastatur-erreichbar">Interaktive Elemente sind nicht per Tastatur erreichbar</h4>
<h5 id="tastaturbedienbarkeit-problem">Problem</h5>
<p>Z. B. ein Menü-Button aus einem <code><div></code>-Element, das sich mit der Maus anklicken lässt, aber beim Tabben übersprungen wird.</p>
<h5 id="tastaturbedienbarkeit-lösung">Lösung:</h5>
<ul>
<li><p>Verwendet standardisierte HTML-Elemente wie <code><button></code>, <code><a></code>, <code><input></code> oder <code><select></code>.</p></li>
<li><p>Wenn ein Element keine native Fokussierbarkeit besitzt, kann es mit tabindex="0" und role="button" sowie passenden Tastatur-Events (onkeydown, onkeypress) barrierefrei gemacht werden.</p></li>
</ul>
<h4 id="tastaturbedienbarkeit-fokus-ist-nicht-sichtbar">Fokus ist nicht sichtbar</h4>
<h5 id="tastaturbedienbarkeit-problem-1">Problem</h5>
<p>Die Webseite lässt sich mit der Tastatur bedienen, aber es ist visuell nicht erkennbar, wo sich der Fokus gerade befindet.</p>
<h5 id="tastaturbedienbarkeit-lösung-1">Lösung:</h5>
<ul>
<li><p>Verzichtet auf outline: none in CSS oder sorgt für eine gut sichtbare alternative Fokusdarstellung.</p></li>
<li><p>Stellt sicher, dass der Fokus-Kontrast mindestens 3:1 zum Hintergrund beträgt (siehe WCAG 2.4.7).</p></li>
<li><p>Nutzt Pseudoklassen wie :focus-visible für moderne, gezielte Anpassungen.</p></li>
</ul>
<h4 id="tastaturbedienbarkeit-die-tab-reihenfolge-ist-unlogisch">Die Tab-Reihenfolge ist unlogisch</h4>
<h5 id="tastaturbedienbarkeit-problem-2">Problem</h5>
<p>Die visuelle Anordnung der Seite passt nicht zur Reihenfolge, in der interaktive Elemente per Tab-Taste erreicht werden.</p>
<h5 id="tastaturbedienbarkeit-lösung-2">Lösung:</h5>
<ul>
<li><p>Achtet darauf, dass die HTML-Struktur der logischen Lesereihenfolge entspricht.</p></li>
<li><p>Vermeidet übermäßigen Einsatz von tabindex > 0 – dies führt zu unnatürlichen Sprüngen.</p></li>
</ul>
<h4 id="tastaturbedienbarkeit-tastaturfalle-man-kommt-nicht-mehr-weiter">Tastaturfalle: Man kommt nicht mehr weiter</h4>
<h5 id="tastaturbedienbarkeit-problem-3">Problem</h5>
<p>Der Fokus bleibt z. B. in einem Overlay oder Dialogfenster „gefangen“ – die Tab-Reihe lässt sich nicht verlassen.</p>
<h5 id="tastaturbedienbarkeit-lösung-3">Lösung:</h5>
<ul>
<li><p>Implementiert Escape- oder Close-Mechanismen.</p></li>
<li><p>Achtet darauf, dass modale Dialoge bei Öffnung den Fokus erhalten und beim Schließen den Fokus zurückgeben.</p></li>
<li><p>Verwendet ARIA aria-modal="true" und aria-labelledby, wenn nötig.</p></li>
</ul>
<h4 id="tastaturbedienbarkeit-dynamische-inhalte-sind-nicht-tastaturbedienbar">Dynamische Inhalte sind nicht tastaturbedienbar</h4>
<h5 id="tastaturbedienbarkeit-problem-4">Problem</h5>
<p>Inhalte werden z. B. durch Mausbewegung oder Hover eingeblendet, sind aber per Tastatur nicht zugänglich.</p>
<h5 id="tastaturbedienbarkeit-lösung-4">Lösung:</h5>
<ul>
<li><p>Bindet Funktionen an Tastaturevents wie onkeydown, onkeyup, onfocus.</p></li>
<li><p>Achtet bei JavaScript-gesteuerten Inhalten darauf, dass alle Benutzerinteraktionen auch mit der Tastatur möglich sind.</p></li>
<li><p>Ergänzt aria-expanded, aria-controls und weitere sinnvolle Attribute.</p></li>
</ul>
<h3 id="tastaturbedienbarkeit-weiterführende-ressourcen">Weiterführende Ressourcen</h3>
<ul>
<li><p><a href="https://handreichungen.bfit-bund.de/bgwa/">Handreichung zur barrierefreien Gestaltung von Webauftritten und Apps</a></p></li>
<li><p><a href="https://handreichungen.bfit-bund.de/barrierefreie-uie/">Barrierefreie Gestaltung von User Interface-Elementen</a></p></li>
</ul>
<h3 id="tastaturbedienbarkeit-checkliste-zur-umsetzung-eine-barrierefreien-tastaturbedienung">Checkliste zur Umsetzung eine barrierefreien Tastaturbedienung</h3>
<ol>
<li><p>Fokus sichtbar und klar gestaltet
</p><ul>
<li><p>Wird der aktuelle Tastaturfokus deutlich angezeigt (z. B. durch Rahmen, Farbe, Unterstreichung)?</p></li>
<li><p>Hat der Fokus-Indikator einen ausreichenden Kontrast zum Hintergrund (mindestens 3:1)?</p></li>
</ul>
</li>
<li><p>Navigierbarkeit ohne Maus vollständig möglich
</p><ul>
<li><p>Lassen sich alle Bedienelemente (z. B. Links, Buttons, Formulare) per Tab-Taste erreichen?</p></li>
<li><p>Können Funktionen (z. B. Menü öffnen, Slider steuern) auch per Tastatur ausgelöst werden?</p></li>
</ul>
</li>
<li><p>Logische Tab-Reihenfolge
</p><ul>
<li><p>Entspricht die Reihenfolge der Fokussierung der visuellen und inhaltlichen Struktur der Seite?</p></li>
<li><p>Gibt es keine Sprünge oder unerwartete Fokuswechsel?</p></li>
</ul>
</li>
<li><p>Keine Tastaturfalle vorhanden
</p><ul>
<li><p>Kann der Fokus alle Bereiche wieder verlassen (z. B. Dialogfenster, Menüs)?</p></li>
<li><p>Wird beim Schließen von Overlays der Fokus korrekt zurückgeführt?</p></li>
</ul>
</li>
<li><p>Nutzung von Standard-HTML und tabindex
</p><ul>
<li><p>Sind möglichst native HTML-Elemente verwendet?</p></li>
<li><p>Ist tabindex nur dort gesetzt, wo es sinnvoll ist – und nie größer als 0?</p></li>
</ul>
</li>
<li><p>Dynamische Inhalte sind über die Tastatur steuerbar
</p><ul>
<li><p>Können Hover-Inhalte, Tooltips oder modale Dialoge auch mit der Tastatur bedient werden?</p></li>
<li><p>Werden Zustände (z. B. auf/zu, ausgewählt) visuell und semantisch vermittelt?</p></li>
</ul>
</li>
<li><p>Getestet mit Tastatur und ggf. Screenreader
</p><ul>
<li><p>Wurde die Seite komplett ohne Maus getestet?</p></li>
<li><p>Wurde die Navigation mit einem Tool wie NVDA überprüft?</p></li>
</ul>
</li>
</ol>
<h2 id="wai-aria">WAI-ARIA</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/technik/wai-aria.html">Online betrachten</a></p>
<p>Dieser Text kann auch als <a
href="@!full_url/pdf/bfmb_wai-aria.pdf">PDF Datei</a> heruntergeladen werden.</p>
<img src="../wai-aria/image2.png" style="" alt="" />
<h3 id="wai-aria-hinweis">Hinweis</h3>
<p>Dieser Text enthält viele technische Begriffe und richtet sich hauptsächlich an Webentwickelnde und Menschen, die mit HTML vertraut sind. Wir beziehen uns im Text auf die gerade aktuelle Version von WAI-ARIA 1.2.</p>
<h3 id="wai-aria-einleitung">Einleitung</h3>
<p>Dynamische und interaktive Webinhalte gehören längst zum Arbeitsalltag vieler Menschen. Doch gerade dort, wo JavaScript die Oberfläche ständig verändert, kommen Screenreader und andere Hilfstechnologien an ihre Grenzen. Hier setzt WAI an, die Web Accessibility Initiative. Sie ist ein technischer Standard des World Wide Web Consortium (W3C). Die WAI-ARIA ist eine Spezifikation der WAI und legt fest, wie Entwickelnde und Frameworks semantische Informationen ergänzen können, damit auch komplexe Webanwendungen zugänglich bleiben.</p>
<p>WAI-ARIA ergänzt HTML um zusätzliche semantische Informationen, insbesondere dort, wo komplexe interaktive Komponenten umgesetzt werden, für die es keine ausreichenden nativen HTML-Elemente gibt. Dazu gehören beispielsweise Menüs, Registerkarten oder dynamische Inhaltsbereiche. ARIA beschreibt Rollen, Zustände und Eigenschaften, die von assistiven Technologien interpretiert werden können.</p>
<p>Grundsätzlich sollte jedoch immer zuerst geprüft werden, ob ein geeignetes HTML-Element verwendet werden kann. Native Elemente wie Buttons, Links oder Formularelemente bringen die notwendige Semantik und Interaktionslogik bereits mit und werden von assistiven Technologien zuverlässig unterstützt.</p>
<p>WAI-ARIA kann zwar auch eingesetzt werden, um solche Funktionen auf generischen Elementen nachzubilden, etwa indem ein div als Button ausgezeichnet wird. Dies sollte jedoch nur in Ausnahmefällen erfolgen, da dabei zusätzliche Anforderungen wie Tastaturbedienbarkeit, Fokussteuerung und Zustandsverwaltung selbst umgesetzt werden müssen und Fehlerquellen entstehen können.</p>
<h3 id="wai-aria-ziel-und-bedeutung">Ziel und Bedeutung</h3>
<p>Ziel von WAI-ARIA ist es, die semantische Bedeutung von interaktiven Elementen für assistive Technologien zugänglich zu machen, insbesondere bei Komponenten wie Registerkarten, Dialogen (z. B. modalen Dialogen), Schiebereglern oder Menüs. Während HTML bereits viele semantische Elemente bereitstellt geht WAI-ARIA weiter:</p>
<ul>
<li><p>Sie ermöglicht die nachträgliche Ergänzung von Semantik, wenn HTML-Strukturen allein nicht ausreichen.</p></li>
<li><p>Sie hilft, Zustände und Veränderungen (etwa „aktiv“, „ausgeblendet“, „ausgewählt“) maschinenlesbar zu machen.</p></li>
<li><p>Sie unterstützt die Navigation in komplexen Strukturen, indem Beziehungen zwischen Elementen beschrieben werden können.</p></li>
</ul>
<h3 id="wai-aria-richtiger-einsatz-von-wai-aria">Richtiger Einsatz von WAI-ARIA</h3>
<p>WAI-ARIA ist ein umfangreiches Werkzeug, aber falsch angewendet führt es schnell zu Problemen. Eingeschränkte Nutzende werden dann eher behindert statt unterstützt. Daher gelten einige grundlegende Regeln, die als Best Practices anerkannt sind.</p>
<h4 id="wai-aria-semantik-vor-wai-aria">Semantik vor WAI-ARIA</h4>
<img src="../wai-aria/image3.png" style="" alt="" />
<p>Semantisch passende HTML-Elemente sollten stets die erste Wahl sein, da sie Bedeutung, Interaktion und Unterstützung durch assistive Technologien bereits mitbringen. WAI-ARIA ergänzt diese Grundlage, wenn HTML allein nicht ausreicht, um komplexe Komponenten oder Zustände verständlich zu machen. Es ist zwar möglich, Funktionen auf generischen Elementen nachzubilden, etwa durch role=“button” auf einem div, dies erfordert jedoch zusätzlichen Aufwand und ist fehleranfällig. Daher sollte immer zuerst geprüft werden, ob eine Lösung mit nativen HTML-Elementen umgesetzt werden kann, bevor WAI-ARIA eingesetzt wird.</p>
<h4 id="wai-aria-keine-doppelte-semantik">Keine doppelte Semantik</h4>
<img src="../wai-aria/image4.png" style="" alt="" />
<p>Wenn ein HTML-Element bereits eine semantische Bedeutung hat, sollte diese beibehalten werden. WAI-ARIA ermöglicht es zwar, Rollen zu ergänzen, zu verändern oder auch zu entfernen, dies erfordert allerdings eine sorgfältige Umsetzung. Insbesondere sollten Rolle, visuelle Darstellung und tatsächliches Verhalten einer Komponente übereinstimmen. Widersprüche, etwa wenn ein Auswahlfeld als Schalter ausgezeichnet wird, können dazu führen, dass assistive Technologien falsche Erwartungen vermitteln und die Bedienung erschwert wird.</p>
<p>Beispiel: Ein <code><button role="link"></code> führt zu widersprüchlichen Ansagen eines Screenreaders, da die durch WAI-ARIA vergebene Rolle von assistiven Technologien übernommen wird. Während visuelle Darstellung und tatsächliches Verhalten weiterhin durch das HTML-Element bestimmt werden. Stimmen diese Aspekte nicht überein, entstehen widersprüchliche Erwartungen, die die Bedienung erschweren können.</p>
<h4 id="wai-aria-wai-aria-attribute-müssen-dynamisch-gepflegt-werden">WAI-ARIA-Attribute müssen dynamisch gepflegt werden</h4>
<img src="../wai-aria/image5.png" style="" alt="" />
<p>Zustände wie aria-expanded, aria-checked oder aria-hidden müssen den aktuellen Zustand widerspiegeln. Diese Aktualisierung erfolgt dann, wenn beim Bedienelement ein Statuswechsel ausgelöst wird. Entwickelnde müssen daher sicherstellen, dass Interaktionen wie bspw. das Öffnen eines Akkordeons auch programmgesteuert den entsprechenden ARIA-Wert anpassen. Bleibt beispielsweise ein Akkordeon visuell geöffnet, aria-expanded jedoch auf false, erhält der Screenreader veraltete Informationen und meldet weiterhin „eingeklappt“, obwohl der Inhalt sichtbar ist.</p>
<h4 id="wai-aria-beziehung-herstellen-nicht-nur-beschreiben">Beziehung herstellen, nicht nur beschreiben</h4>
<img src="../wai-aria/image6.png" style="" />
<p>Aria-labelledby und aria-describedby sind oft aria-label vorzuziehen, weil sie Beziehungen zwischen sichtbarem und unsichtbarem Text herstellen. So bleibt der Kontext erhalten und redundante Beschriftung wird vermieden. Aria-label eignet sich vor allem dort, wo es keinen sinnvollen sichtbaren Text gibt.</p>
<h4 id="wai-aria-verstecken-mit-bedacht">Verstecken mit Bedacht</h4>
<img src="../wai-aria/image7.png" style="" alt="" />
<p>Ein aria-hidden Attribute mit dem Wert true entfernt ein Element aus der Wahrnehmung von Screenreadern. Wird es unüberlegt gesetzt, verschwinden wichtige Inhalte, zum Beispiel ein sichtbarer Warnhinweis. Sichtbar bedeutet nicht automatisch zugänglich.</p>
<h4 id="wai-aria-prüfen-in-realen-umgebungen">Prüfen in realen Umgebungen</h4>
<img src="../wai-aria/image8.png" style="" alt="" />
<p>Assistive Technologien interpretieren WAI-ARIA unterschiedlich. Daher ist das Testen mit Screenreadern wie beispielsweise: NVDA, JAWS, VoiceOver oder TalkBack unverzichtbar. Automatische Tools können helfen, ersetzen aber keine echte Nutzungsprüfung.</p>
<h3 id="wai-aria-überblick-über-zentrale-wai-aria-attribute">Überblick über zentrale WAI-ARIA-Attribute</h3>
<p>Die folgende Übersicht erläutert einige wichtige Rollen und Attribute in WAI-ARIA 1.2 und erklärt ihren Zweck in einfachen Worten.</p>
<table>
<colgroup>
<col style="width: 27%" />
<col style="width: 23%" />
<col style="width: 25%" />
<col style="width: 23%" />
</colgroup>
<thead>
<tr>
<th>Kategorie</th>
<th>Attribut / Rolle</th>
<th>Beschreibung</th>
<th>Beispielhafte Anwendung</th>
</tr>
</thead>
<tbody>
<tr>
<th>Struktur und Navigation</th>
<td>role="navigation"</td>
<td>Kennzeichnet einen Bereich mit Navigationslinks.</td>
<td>Hauptmenü, Footer-Navigation</td>
</tr>
<tr>
<th>Struktur und Navigation</th>
<td>role="banner"</td>
<td>Oberer Seitenbereich, meist mit Logo oder Titel.</td>
<td>Kopfzeile einer Website</td>
</tr>
<tr>
<th>Struktur und Navigation</th>
<td>role="main"</td>
<td>Hauptinhalt der Seite, einzigartig pro Seite.</td>
<td>Inhaltsbereich eines Artikels</td>
</tr>
<tr>
<th>Struktur und Navigation</th>
<td>role="contentinfo"</td>
<td>Fußbereich mit Impressum, Kontakt etc.</td>
<td>Seitenfooter</td>
</tr>
<tr>
<th>Struktur und Navigation</th>
<td>role="region" + aria-label</td>
<td>Beschrifteter Inhaltsabschnitt.</td>
<td>„Ergebnisse der Suche“</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="button"</td>
<td>Kennzeichnet klickbares Steuerelement.</td>
<td>Custom-Button</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="dialog" + aria-modal="true"</td>
<td>Modales Fenster; blockiert Hintergrund.</td>
<td>Login-Dialog</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="tablist", role="tab", role="tabpanel"</td>
<td>Struktur für Reiter-Navigation.</td>
<td>Registerkarten</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="menu", role="menuitem"</td>
<td>Menü oder Kontextmenü.</td>
<td>Dropdown in App</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="checkbox", aria-checked</td>
<td>Kontrollkästchen mit Zustand.</td>
<td>„Ich stimme zu“</td>
</tr>
<tr>
<th>Widgets und Interaktion</th>
<td>role="switch"</td>
<td>Umschalter zwischen zwei Zuständen.</td>
<td>Dark-Mode-Schalter</td>
</tr>
<tr>
<th>Status und Hinweise</th>
<td>role="alert"</td>
<td>Sofortige, wichtige Meldung.</td>
<td>Fehlermeldung bei Formular</td>
</tr>
<tr>
<th>Status und Hinweise</th>
<td>role="status"</td>
<td>Informative Änderung ohne Fokusänderung.</td>
<td>„Speichern abgeschlossen“</td>
</tr>
<tr>
<th>Status und Hinweise</th>
<td>aria-live="polite" / "assertive"</td>
<td>Bereich mit dynamischen Inhalten.</td>
<td>Chatnachrichten, Ladezustände</td>
</tr>
<tr>
<th>Beschriftung und Beziehungen</th>
<td>aria-label</td>
<td>Unsichtbare Kurzbeschreibung.</td>
<td>Symbol-Button ohne Text</td>
</tr>
<tr>
<th>Beschriftung und Beziehungen</th>
<td>aria-labelledby</td>
<td>Verknüpft mit sichtbarem Label.</td>
<td>Überschrift beschreibt Widget</td>
</tr>
<tr>
<th>Beschriftung und Beziehungen</th>
<td>aria-describedby</td>
<td>Verweist auf erläuternden Text.</td>
<td>Hilfetext für Eingabefeld</td>
</tr>
<tr>
<th>Beschriftung und Beziehungen</th>
<td>aria-details</td>
<td>Verknüpft ergänzende Informationen.</td>
<td>Verweis auf lange Beschreibung</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-expanded</td>
<td>Zeigt an, ob ein Bereich geöffnet ist.</td>
<td>Akkordeon</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-hidden</td>
<td>Verbirgt Element vor Screenreader.</td>
<td>Unsichtbare Inhalte</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-pressed</td>
<td>Zustand eines Toggle-Buttons.</td>
<td>„Favorit aktiv“</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-disabled</td>
<td>Element ist deaktiviert, aber sichtbar.</td>
<td>Inaktive Schaltfläche</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-required</td>
<td>Feld muss ausgefüllt werden.</td>
<td>Pflichtfeld in Formular</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-invalid</td>
<td>Markiert fehlerhafte Eingabe.</td>
<td>„E-Mail ungültig“</td>
</tr>
<tr>
<th>Zustände und Eigenschaften</th>
<td>aria-current</td>
<td>Aktives oder ausgewähltes Element.</td>
<td>Aktueller Menüpunkt</td>
</tr>
</tbody>
</table>
<h3 id="wai-aria-checkliste-zum-einsatz-von-aria-attributen">Checkliste zum Einsatz von ARIA Attributen</h3>
<h4 id="wai-aria-grundprinzipien">Grundprinzipien</h4>
<ul>
<li><p>Weniger ist mehr: ARIA nur einsetzen, wenn HTML keine passende Lösung bietet.</p></li>
<li><p>Semantik testen: Screenreader-Ausgabe prüfen – stimmt sie mit der visuellen Darstellung überein?</p></li>
<li><p>Pflege sicherstellen: Bei jeder dynamischen Änderung (Ein- oder Ausblenden, Öffnen, Umschalten) müssen ARIA-Zustände aktualisiert werden.</p></li>
<li><p>Dokumentation führen: Festlegen, welche ARIA-Attribute im Projekt erlaubt oder untersagt sind und warum.</p></li>
</ul>
<h4 id="wai-aria-erweiterte-prüfpunkte">Erweiterte Prüfpunkte</h4>
<ul>
<li><p>Richtige Rollen verwenden: Prüfen, ob die zugewiesene role-Eigenschaft der tatsächlichen Funktion entspricht (zum Beispiel role=“dialog” nur für echte Dialoge).</p></li>
<li><p>Zustände korrekt setzen: Attribute wie aria-expanded, aria-pressed oder aria-selected müssen den aktuellen UI-Zustand widerspiegeln.</p></li>
<li><p>Beziehungen prüfen: Wenn aria-labelledby oder aria-describedby verwendet wird, müssen die referenzierten IDs existieren und eindeutig sein.</p></li>
<li><p>ARIA und Fokus gemeinsam denken: Ein Element mit role=“dialog” oder role=“alertdialog” muss beim Öffnen den Tastaturfokus korrekt setzen.</p></li>
<li><p>Verstecken mit Bedacht: aria-hidden=“true” darf nicht auf sichtbare, relevante Inhalte angewendet werden. Sichtbar bedeutet nicht automatisch zugänglich.</p></li>
<li><p>Konsistenz über Komponenten sicherstellen: Gleiche Komponenten (zum Beispiel Akkordeons oder Tabs) müssen ARIA-Attribute konsistent verwenden.</p></li>
<li><p>Frameworks prüfen: Überprüfen, welche ARIA-Werte von Frameworks wie React, Angular oder Vue automatisch gesetzt werden und welche ergänzt werden müssen.</p></li>
<li><p>Test mit Assistive Technologien: Die Umsetzung immer mit mindestens einem Screenreader und Tastatur testen, um vorhersehbares Verhalten sicherzustellen.</p></li>
<li><p>Keine widersprüchliche Semantik: Native HTML-Rollen dürfen nicht durch role überschrieben werden (zum Beispiel kein <code><button role="link"></code>).</p></li>
<li><p>ARIA und Live-Regionen prüfen: aria-live-Bereiche gezielt einsetzen und sicherstellen, dass Statusmeldungen tatsächlich vorgelesen werden.</p></li>
</ul>
<h3 id="wai-aria-weitere-informationen">Weitere Informationen</h3>
<ul>
<li><p><a href="https://www.w3.org/TR/wai-aria/">Offizielle Spezifikation: <span lang="en">W3C Recommendation – Accessible Rich Internet Applications (WAI-ARIA) 1.2</span></a></p></li>
<li><p><a href="https://www.w3.org/WAI/ARIA/apg">Begleitdokument: <span lang="en">ARIA Authoring Practices Guide (APG)</span></a></p></li>
<li><p><a href="https://www.w3.org/TR/html-aria/">Begleitdokument: <span lang="en">ARIA in HTML</span></a></p></li>
<li><p><a href="https://www.w3.org/TR/using-aria/">Begleitdokument: <span lang="en">Using ARIA </span></a></p></li>
<li><p><a href="https://www.w3.org/WAI/WCAG22/Techniques/#aria">Begleitdokument: <span lang="en">Techniques for WCAG 2.2</span></a></p></li>
</ul>
<h2 id="anhang-lizenzinformationen-für-diese-handreichung">Anhang: Lizenzinformationen für diese Handreichung</h2>
<p><a href="@!full_url/bfit-leitfaeden/5.0/lizenz.html">Online betrachten</a></p>
<p>Diese Handreichung wird unter der Lizenz <a href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">CC-BY-SA 4.0</a> veröffentlicht. Sie können Sie bearbeiten und unter Namensnennung und mit gleicher Lizenz weiterverbreiten. Wenn Sie Teile davon verändern, müssen Sie das entsprechend kennzeichnen.</p>
<h2>Informationen zu diesem Dokument</h2>
<p>Diese Handreichung hat die Version 5.0 und wurde am 26.06.2026 erstellt.</p>
<h3>Allgemeine Informationspflichten gemäß § 5 Telemediengesetz und § 55 Rundfunkstaatsvertrag</h3>
<p>Die Deutsche Rentenversicherung Knappschaft-Bahn-See ist eine rechtsfähige Körperschaft des öffentlichen Rechts mit Selbstverwaltung und besitzt Dienstherrnfähigkeit (§ 29 SGB IV in Verbindung mit § 143 Abs. 1 SGB VI).</p>
<p>Dieses Impressum gilt für dieses Dokument der Arbeitsgruppen des Ausschusses für barrierefreie Informationstechnik nach § 5 BITV 2.0. Die Arbeitsgruppen werden von der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik organisiert.</p>
<h3>Herausgeber</h3>
<p>Deutsche Rentenversicherung Knappschaft-Bahn-See<br/>
Pieperstraße 14 - 28<br/>
44789 Bochum<br/>
Tel. 0234 304 - 0<br/>
Fax 0234 304 - 66050<br/>
E-Mail an die Zentrale der KBS: <a href="mailto:zentrale@kbs.de">zentrale@kbs.de</a></p>
<p>Umsatzsteuer-Identifikationsnummer: DE 124089627</p>
<p>Dieses Dokument wird herausgegeben von der Deutschen Rentenversicherung Knappschaft-Bahn-See, vertreten durch die Geschäftsführung, Dr. Rainer Wilhelm.</p>
<h3>Zuständige Fachaufsichtsbehörde für die Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik</h3>
<p>Bundesministerium für Arbeit und Soziales<br/>
Wilhelmstraße 49<br/>
10117 Berlin
</p>
<h3>Nutzungsbedingungen</h3>
<p>Die Inhalte dieser Handreichung werden mit größtmöglicher Sorgfalt verfasst. Unser Anspruch ist es, richtige, vollständige und aktuelle Inhalte bereitzustellen. Wir übernehmen dennoch keine Gewähr für versehentlich gemachte falsche Angaben.</p>
<p>Diese Handreichung enthält Verknüpfungen zu Webauftritten Dritter (“externe Links”). Wir haben bei der erstmaligen Verknüpfung zu externen Links die fremden Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt haben wir keine Rechtsverstöße vorgefunden. Wir haben jedoch weder Einfluss auf die aktuelle und zukünftige Gestaltung der verknüpften Seiten noch auf deren Inhalte oder Angebote. Sollten uns Rechtsverstöße bekannt werden, löschen wir die betreffenden externen Links unverzüglich. Bitte weisen Sie uns gegebenenfalls darauf hin.</p>
</body>
</html>
