Anleitungen zu WCAG-Erfolgskriterien: Regeltext, Nutzen für Nutzer:innen, Prüfschritte und Maßnahmen für Teams, die mit accsible barrierefreie Websites ausliefern.
90 / 90
WCAG 1.1.1 verlangt, dass alle Nicht-Text-Inhalte – Bilder, Symbole, Steuerelemente und Medien – eine Textalternative haben, die denselben Zweck oder dieselben Informationen vermittelt, sodass Nutzerinnen und Nutzer, die visuelle Inhalte nicht wahrnehmen können, über unterstützende Technologien wie Screenreader darauf zugreifen können.
WCAG 1.2.1 verlangt, dass für vorab aufgezeichnete rein auditive und rein visuelle Inhalte eine textbasierte oder mediale Alternative bereitgestellt wird, damit Nutzer, die das Medium nicht hören oder sehen können, dennoch auf die Informationen zugreifen können. Dies ist eine Anforderung der Stufe A, was bedeutet, dass sie das minimale Basisniveau für die Einhaltung der Barrierefreiheitsanforderungen im Web darstellt.
WCAG 1.2.2 verlangt, dass alle vorab aufgezeichneten Audioinhalte in synchronisierten Medien (Video mit Audio) genaue Untertitel enthalten. Dies stellt sicher, dass gehörlose und schwerhörige Nutzer auf gesprochene Dialoge, Soundeffekte und andere bedeutungsvolle Audioinformationen zugreifen können.
WCAG 1.2.3 verlangt, dass für vorab aufgezeichnete synchronisierte Medien (Video mit Audio) entweder eine Audiodeskription der visuellen Inhalte oder eine vollständige Textalternative bereitgestellt wird, damit Nutzerinnen und Nutzer, die blind sind oder eine Sehbehinderung haben, auf visuell vermittelte Informationen zugreifen können.
WCAG 1.3.1 verlangt, dass Informationen, Struktur und Beziehungen, die durch visuelle Darstellung vermittelt werden, auch programmatisch ermittelt werden können oder in Textform verfügbar sind, sodass Nutzer von unterstützenden Technologien denselben strukturellen Kontext erhalten wie sehende Nutzer.
WCAG 1.3.2 verlangt, dass, wenn die Reihenfolge von Inhalten ihre Bedeutung beeinflusst, diese Abfolge programmatisch bestimmbar sein muss, damit unterstützende Technologien sie korrekt präsentieren können. Wird dieses Kriterium nicht erfüllt, erhalten Screenreader-Nutzende und andere AT-Nutzende Inhalte in einer verwirrenden oder sinnlosen Reihenfolge.
WCAG 1.3.3 verlangt, dass Anweisungen zur Nutzung von Inhalten sich nicht ausschließlich auf sensorische Merkmale wie Form, Farbe, Größe, visuelle Position, Ausrichtung oder Klang stützen. Dies stellt sicher, dass Nutzer, die diese sensorischen Hinweise aufgrund von Blindheit, Farbenblindheit, Taubheit oder anderen Behinderungen nicht wahrnehmen können, dennoch alle Funktionen verstehen und bedienen können.
WCAG 1.4.1 verlangt, dass Farbe niemals das einzige Mittel ist, um Informationen zu vermitteln, eine Aktion anzuzeigen, eine Reaktion auszulösen oder ein visuelles Element zu unterscheiden. Dieses Kriterium stellt sicher, dass Nutzer, die Farbunterschiede nicht wahrnehmen können – einschließlich Menschen mit Farbenblindheit oder Sehschwäche – weiterhin auf alle Inhalte und Funktionen zugreifen können.
WCAG 1.4.2 verlangt, dass jede Audioausgabe, die automatisch länger als drei Sekunden abgespielt wird, den Nutzern eine Möglichkeit bieten muss, sie zu pausieren, zu stoppen oder ihre Lautstärke unabhängig von der Systemlautstärke zu regeln. Dies verhindert, dass Audio die Ausgabe von Screenreadern stört, und schützt Nutzer vor unerwarteten, desorientierenden Geräuschen.
WCAG 2.1.1 verlangt, dass alle Funktionen, die über eine Maus oder einen Zeiger verfügbar sind, gleichermaßen ausschließlich über die Tastatur bedienbar sind, ohne dass ein bestimmtes Timing für Tastenanschläge erforderlich ist. Dieses Kriterium ist grundlegend für Nutzer, die keine Maus verwenden können, und stellt sicher, dass sie auf jeder Website oder in jeder Anwendung navigieren, interagieren und Aufgaben ausführen können.
WCAG 2.1.2 verlangt, dass Tastaturnutzende niemals in einer Komponente gefangen sind – wenn der Fokus mithilfe der Tastatur in ein UI-Element verschoben werden kann, muss es auch möglich sein, den Fokus ausschließlich mit der Tastatur wieder daraus zu entfernen. Dieses Kriterium ist entscheidend für Nutzende, die sich ausschließlich auf die Tastaturnavigation verlassen, einschließlich Menschen mit motorischen Beeinträchtigungen und Screenreader-Nutzenden.
WCAG 2.1.4 verlangt, dass jede Tastenkombination, die nur eine einzelne Zeichentaste (Buchstabe, Zahl, Satzzeichen oder Symbol) verwendet, deaktiviert, neu zugeordnet oder nur bei Fokus aktiviert werden kann – um unbeabsichtigte Auslösungen zu verhindern, die Nutzer schädigen, die auf Spracheingabe angewiesen sind oder motorische Beeinträchtigungen haben.
- Ich werde den ursprünglichen Sinn, Ton und Stil beibehalten. - Ich werde die formelle Anrede und den fachlichen Kontext berücksichtigen. - Ich werde alle Zahlen, Bezüge auf Normen und Fachbegriffe korrekt übertragen. - Ich werde Zeilenumbrüche und Absatzstruktur exakt erhalten. - Ich werde die Übersetzung kurz prüfen und bei Bedarf korrigieren. WCAG 2.2.1 verlangt, dass jede durch Inhalte festgelegte Zeitbegrenzung von den Nutzern deaktiviert, angepasst oder verlängert werden kann – um sicherzustellen, dass Menschen, die mehr Zeit für die Interaktion mit Webinhalten benötigen, nicht ausgeschlossen werden. Dieses Kriterium der Stufe A ist für Nutzer mit motorischen, kognitiven und visuellen Beeinträchtigungen unerlässlich.
- Ich werde den ursprünglichen Sinn, Ton und Stil beibehalten. - Ich werde die formelle Anrede und den fachlichen Kontext berücksichtigen. - Ich werde alle Zahlen, Bezüge auf Normen und Fachbegriffe korrekt übertragen. - Ich werde Zeilenumbrüche und Absatzstruktur exakt erhalten. - Ich werde die Übersetzung kurz prüfen und bei Bedarf selbst korrigieren. WCAG 2.2.2 verlangt, dass sich bewegende, blinkende, scrollende oder sich automatisch aktualisierende Inhalte von Nutzerinnen und Nutzern angehalten, gestoppt oder ausgeblendet werden können. Dies schützt Menschen mit kognitiven Beeinträchtigungen, vestibulären Störungen und aufmerksamkeitsspezifischen Beeinträchtigungen vor Inhalten, die sie nicht steuern können.
WCAG 2.3.1 verlangt, dass Webinhalte nichts enthalten, das mehr als dreimal pro Sekunde aufblitzt, es sei denn, das Aufblitzen liegt unter den allgemeinen oder roten Blitzschwellen. Dieses Kriterium ist entscheidend, um Anfälle und körperliche Reaktionen bei Nutzern mit fotosensitiver Epilepsie oder ähnlichen neurologischen Erkrankungen zu verhindern.
WCAG 2.4.1 verlangt, dass Webseiten eine Möglichkeit bieten, wiederholte Inhaltsblöcke, wie Navigationsmenüs, zu überspringen, damit Tastatur- und Assistenztechnologie-Nutzende den Hauptinhalt erreichen können, ohne sich durch jeden einzelnen Link durchtabben zu müssen. Dies ist eine Anforderung der Stufe A, was bedeutet, dass sie die Grundlage für eine barrierefreie Tastaturnavigation bildet.
WCAG 2.4.2 verlangt, dass jede Webseite einen beschreibenden, aussagekräftigen Titel hat, der ihr Thema oder ihren Zweck identifiziert. Dies stellt sicher, dass sich Nutzer – insbesondere diejenigen, die auf Screenreader angewiesen sind oder mehrere Tabs verwalten – schnell orientieren und effizient navigieren können.
WCAG 2.4.3 verlangt, dass, wenn eine Webseite sequentiell navigiert werden kann und die Navigationssequenzen Bedeutung oder Funktion beeinflussen, fokussierbare Komponenten den Fokus in einer Reihenfolge erhalten müssen, die Bedeutung und Bedienbarkeit bewahrt. Dieses Kriterium ist entscheidend für Tastatur- und Assistenztechnologie-Nutzer, die auf eine logische, vorhersehbare Fokusreihenfolge angewiesen sind, um Inhalte zu verstehen und mit ihnen zu interagieren.
WCAG 2.4.4 verlangt, dass der Zweck jedes Links entweder allein aus dem Linktext oder aus dem Linktext zusammen mit seinem umgebenden Kontext bestimmt werden kann. Dies stellt sicher, dass Screenreader-Nutzer, ausschließlich die Tastatur verwendende Nutzer und Menschen mit kognitiven Beeinträchtigungen verstehen können, wohin ein Link führt, ohne ihm folgen zu müssen.
WCAG 2.5.1 verlangt, dass alle Funktionen, die Mehrpunkt- oder pfadbasierte Gesten verwenden (wie zum Beispiel Pinch-to-Zoom oder Wischen), auch mit einem einzelnen Zeiger ohne pfadbasierte Geste bedient werden können, es sei denn, die Geste ist wesentlich. Dies schützt Nutzer mit motorischen Beeinträchtigungen, die komplexe Touch-Gesten nicht zuverlässig ausführen können.
WCAG 2.5.2 verlangt, dass Funktionen, die durch einen einzelnen Zeiger (Maus, Touch oder Stift) ausgelöst werden, abgebrochen oder rückgängig gemacht werden können, um unbeabsichtigte Auslösungen zu verhindern. Dies schützt Nutzer mit motorischen Beeinträchtigungen, die möglicherweise versehentlich tippen oder klicken.
WCAG 2.5.3 verlangt, dass interaktive Komponenten mit sichtbaren Textbeschriftungen einen zugänglichen Namen haben, der den sichtbaren Text enthält, damit Nutzer von Spracheingabe Steuerelemente aktivieren können, indem sie aussprechen, was sie sehen. Abweichungen zwischen sichtbaren Beschriftungen und zugänglichen Namen unterbrechen die Sprachsteuerungsnavigation und untergraben das Vertrauen von Millionen von Nutzern.
WCAG 2.5.4 verlangt, dass jede Funktionalität, die durch Bewegungen des Geräts oder des Nutzers (wie Schütteln oder Neigen) ausgelöst wird, auch über herkömmliche Benutzeroberflächenkomponenten bedienbar ist und dass Nutzer die Bewegungssteuerung deaktivieren können müssen, um eine unbeabsichtigte Aktivierung zu verhindern.
WCAG 3.1.1 verlangt, dass die Standardsprache jeder Webseite programmatisch ermittelt werden kann, hauptsächlich durch das Setzen eines gültigen lang-Attributs auf dem HTML-Element. Dies ermöglicht unterstützenden Technologien wie Screenreadern, Inhalte korrekt auszusprechen, und hilft Nutzern mit kognitiven und sprachbezogenen Beeinträchtigungen, die Seite zu verstehen.
WCAG 3.2.1 On Focus verlangt, dass, wenn eine beliebige Benutzeroberflächenkomponente den Tastaturfokus erhält, dies keine unerwartete Kontextänderung auslösen darf. Dies schützt Tastatur- und Assistenztechnologie-Nutzende vor desorientierendem, unvorhersehbarem Verhalten, das eine Seite praktisch unmöglich zu einer effektiven Navigation machen kann.
WCAG 3.2.2 „On Input“ verlangt, dass das Ändern der Einstellung einer beliebigen Benutzeroberflächenkomponente nicht automatisch einen Kontextwechsel verursacht, es sei denn, der Nutzer wurde vorher über dieses Verhalten informiert. Dies schützt Nutzer vor desorientierenden, unerwarteten Seitenänderungen, die durch Formularinteraktionen ausgelöst werden.
WCAG 3.3.1 verlangt, dass, wenn ein Eingabefehler automatisch erkannt wird, das fehlerhafte Element identifiziert und der Fehler dem Nutzer in Textform beschrieben wird. Dies stellt sicher, dass Nutzer mit Behinderungen Fehler beim Ausfüllen von Formularen erkennen, verstehen und korrigieren können.
WCAG 3.3.2 verlangt, dass Beschriftungen oder Anweisungen bereitgestellt werden, wenn Inhalte eine Eingabe durch die Nutzer erfordern, um sicherzustellen, dass alle Nutzer – unabhängig von ihren Fähigkeiten – verstehen können, was von ihnen erwartet wird, bevor sie Formulardaten absenden. Das Versäumnis, Formularfelder zu beschriften, ist eine der häufigsten und folgenreichsten Barrieren für Barrierefreiheit im Web.
WCAG 3.3.7 verlangt, dass Informationen, die Nutzer bereits in einem mehrstufigen Prozess angegeben haben, entweder automatisch ausgefüllt oder zur Auswahl bereitgestellt werden, sodass Nutzer dieselben Daten niemals zweimal eingeben müssen. Dies verhindert Frustration und Fehler bei Nutzern mit kognitiven, motorischen oder anderen Beeinträchtigungen.
WCAG 4.1.2 verlangt, dass alle Benutzeroberflächenkomponenten einen programmatisch bestimmbaren Namen und eine programmatisch bestimmbare Rolle haben und dass Zustände, Eigenschaften und Werte sowohl von unterstützenden Technologien ausgelesen als auch gesetzt werden können. Dies stellt sicher, dass Screenreader und andere Werkzeuge jedes Element auf der Seite korrekt identifizieren, beschreiben und mit ihm interagieren können.
WCAG 1.2.4 verlangt, dass alle Live-Audioinhalte in synchronisierten Medien – wie Webinare, Livestreams und Übertragungen – von Echtzeit-Untertiteln begleitet werden. Dies stellt sicher, dass gehörlose und schwerhörige Nutzerinnen und Nutzer auf gesprochene Inhalte zugreifen können, während sie stattfinden, in Echtzeit.
WCAG 1.2.5 verlangt, dass für alle vorab aufgezeichneten Videoinhalte in synchronisierten Medien eine Audiodeskription bereitgestellt wird, um sicherzustellen, dass Nutzerinnen und Nutzer, die blind sind oder eine Sehbehinderung haben, auf visuelle Informationen zugreifen können, die nicht allein über die Tonspur vermittelt werden.
WCAG 1.3.4 Ausrichtung verlangt, dass Inhalte ihre Ansicht und Bedienung nicht auf eine einzige Bildschirmausrichtung wie Hoch- oder Querformat beschränken, es sei denn, eine bestimmte Ausrichtung ist wesentlich. Dieses Kriterium stellt sicher, dass Nutzer, die ihre Geräte nicht physisch drehen können – etwa Personen mit fest montierten Tablets oder motorischen Beeinträchtigungen – weiterhin auf alle Inhalte zugreifen können.
WCAG 1.3.5 verlangt, dass der Zweck jedes Eingabefeldes, das personenbezogene Daten erfasst, programmatisch ermittelt werden kann, sodass Browser und unterstützende Technologien Felder automatisch ausfüllen, beschriften oder anpassen können. Dies ist besonders wichtig für Nutzer mit kognitiven Beeinträchtigungen und motorischen Einschränkungen, die von einer reduzierten manuellen Eingabe profitieren.
WCAG 1.4.3 verlangt, dass Text und Bilder von Text ein Kontrastverhältnis von mindestens 4,5:1 zu ihrem Hintergrund aufweisen (3:1 für großen Text), um sicherzustellen, dass Nutzer mit Sehschwäche oder Farbsehschwächen Inhalte ohne unterstützende Technologien lesen können.
WCAG 1.4.4 verlangt, dass Text ohne unterstützende Technologien und ohne Verlust von Inhalt oder Funktionalität auf bis zu 200 % vergrößert werden kann. Dieses Kriterium ist entscheidend für Nutzer mit eingeschränktem Sehvermögen, die auf die Zoomfunktion des Browsers oder benutzerdefinierte Schriftgrößeneinstellungen angewiesen sind, um Webinhalte komfortabel lesen zu können.
WCAG 1.4.5 verlangt, dass Informationen vermittelnder Text als echter Text und nicht als Bild von Text dargestellt wird, außer wenn eine bestimmte visuelle Darstellung wesentlich ist oder das Bild vom Nutzer visuell angepasst werden kann. Dieses Kriterium ist entscheidend für Nutzer, die Text vergrößern, umfärben oder den Zeilenumbruch anpassen müssen, um ihn bequem lesen zu können.
WCAG 1.4.10 Reflow verlangt, dass Inhalte ohne Informations- oder Funktionsverlust und ohne zweidimensionales Scrollen dargestellt werden können, wenn sie mit einer Breite von 320 CSS-Pixeln angezeigt werden. Dies stellt sicher, dass Nutzer, die auf Zoom oder kleine Viewports angewiesen sind – einschließlich Menschen mit Sehbehinderungen und mobilen Nutzern – auf alle Inhalte zugreifen können, ohne horizontal scrollen zu müssen.
WCAG 1.4.11 verlangt, dass Benutzeroberflächenkomponenten und grafische Objekte ein Kontrastverhältnis von mindestens 3:1 zu angrenzenden Farben aufweisen, damit Menschen mit Sehbeeinträchtigungen interaktive Steuerelemente, Fokusindikatoren und bedeutungsvolle Grafiken ohne unterstützende Technologien wahrnehmen können.
WCAG 1.4.12 verlangt, dass kein Verlust von Inhalt oder Funktionalität auftritt, wenn Nutzerinnen und Nutzer Textabstandseigenschaften – Zeilenhöhe, Zeichenabstand, Wortabstand und Abstand nach Absätzen – auf bestimmte Mindestwerte überschreiben. Dieses Kriterium ist entscheidend für Menschen mit Legasthenie, Sehbeeinträchtigungen und kognitiven Beeinträchtigungen, die auf benutzerdefinierte Abstände angewiesen sind, um effektiv lesen zu können.
WCAG 1.4.13 verlangt, dass zusätzlicher Inhalt, der beim Bewegen des Zeigers oder beim Tastaturfokus erscheint, abweisbar, hoverbar und persistent ist – damit sichergestellt ist, dass Nutzer mit Sehbeeinträchtigungen, motorischen Einschränkungen und kognitiven Behinderungen auf Tooltip-ähnliche Inhalte zugreifen und mit ihnen interagieren können, ohne sie unerwartet zu verlieren.
WCAG 2.4.5 verlangt, dass Websites mehr als eine Möglichkeit bieten, damit Nutzerinnen und Nutzer eine beliebige Seite innerhalb einer Gruppe von Webseiten finden können – zum Beispiel über eine Seitensuche, eine Sitemap oder ein Navigationsmenü. Dies stellt sicher, dass Menschen mit unterschiedlichen Fähigkeiten und Vorlieben Inhalte auf die Weise finden können, die für sie am besten funktioniert.
WCAG 2.4.6 verlangt, dass Überschriften und Beschriftungen, sofern vorhanden, aussagekräftig sind und das Thema oder den Zweck des Inhalts, den sie einführen oder kennzeichnen, korrekt wiedergeben. Dieses Kriterium hilft Nutzerinnen und Nutzern – insbesondere solchen, die unterstützende Technologien verwenden – Inhalte effizient zu navigieren und die Struktur und den Zweck von Seitenbereichen und Formularfeldern zu verstehen.
WCAG 2.4.7 verlangt, dass jede mit der Tastatur bedienbare Benutzeroberfläche einen sichtbaren Fokusindikator hat, damit Nutzer jederzeit sehen können, welches Element aktuell den Tastaturfokus hat. Dies ist unerlässlich für Nutzer, die ausschließlich die Tastatur verwenden, Menschen mit motorischen Beeinträchtigungen und alle, die keine Maus verwenden können.
WCAG 2.4.11 verlangt, dass eine UI-Komponente, wenn sie den Tastaturfokus erhält, nicht vollständig durch vom Autor erstellte Inhalte wie Sticky-Header, Cookie-Banner oder Chat-Widgets verdeckt wird. Dieses Kriterium stellt sicher, dass Tastaturnutzende immer sehen können, wo sie sich auf der Seite befinden, was für Navigation und Benutzerfreundlichkeit unerlässlich ist.
WCAG 2.5.7 verlangt, dass jede Funktionalität, die eine Ziehbewegung verwendet, auch mit einem einzelnen Zeiger ohne Ziehen ausgeführt werden kann, es sei denn, das Ziehen ist wesentlich. Dies stellt sicher, dass Nutzer mit motorischen Beeinträchtigungen, die Ziehgesten nicht zuverlässig ausführen können, weiterhin auf alle Funktionalitäten zugreifen können.
WCAG 2.5.8 verlangt, dass interaktive Ziele wie Schaltflächen und Links eine Mindestgröße von 24×24 CSS-Pixeln haben oder dass um kleinere Ziele herum ausreichend Abstand vorhanden ist, damit Nutzerinnen und Nutzer mit motorischen Beeinträchtigungen sie zuverlässig aktivieren können. Wird dieses Kriterium nicht erfüllt, führt dies zu unbeabsichtigten Aktivierungen und Frustration bei allen, die einen Zeiger nicht präzise steuern können.
WCAG 3.1.2 verlangt, dass jede Passage, Phrase oder jeder Abschnitt von Webinhalten, der in einer anderen Sprache als der Hauptsprache der Seite verfasst ist, programmatisch mithilfe des lang-Attributs gekennzeichnet wird. Dies ermöglicht unterstützenden Technologien, insbesondere Screenreadern, automatisch die Sprachausgabe umzuschalten und Inhalte für Nutzerinnen und Nutzer, die auf Audioausgabe angewiesen sind, korrekt wiederzugeben.
- Ich werde den ursprünglichen Sinn, Ton und Stil des Textes beibehalten. - Ich werde die formelle Anrede und den fachlichen Kontext korrekt ins Deutsche übertragen. - Ich werde alle Zahlen, Bezüge auf Richtlinien und Fachbegriffe exakt übernehmen. - Ich werde die ursprünglichen Zeilenumbrüche und Absatzstruktur unverändert lassen. - Ich werde die Übersetzung kurz prüfen und bei Bedarf selbst korrigieren. WCAG 3.2.3 verlangt, dass Navigationsmechanismen, die auf mehreren Seiten innerhalb eines Satzes von Webseiten erscheinen, jedes Mal in derselben relativen Reihenfolge vorkommen, es sei denn, der Nutzer initiiert eine Änderung. Diese Vorhersehbarkeit hilft Nutzern mit kognitiven, visuellen und motorischen Beeinträchtigungen, mentale Modelle einer Website aufzubauen und effizient zu navigieren.
WCAG 3.2.4 verlangt, dass Komponenten, die auf einer Website dieselbe Funktion erfüllen, einheitlich gekennzeichnet werden – jedes Mal, wenn sie erscheinen, mit demselben Label, Namen oder Alternativtext. Dies verhindert Verwirrung bei Nutzern, die auf konsistente Muster angewiesen sind, um sich in digitalen Oberflächen zurechtzufinden und sie zu verstehen.
WCAG 3.2.6 verlangt, dass, wenn eine Website menschlichen Kontakt, Selbsthilfe- oder automatisierte Unterstützungsmechanismen anbietet, diese Mechanismen auf allen Seiten in derselben relativen Reihenfolge erscheinen. Dies stellt sicher, dass Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen oder Gedächtnisstörungen Hilfe zuverlässig finden können, ohne die Benutzeroberfläche auf jeder Seite neu erlernen zu müssen.
WCAG 3.3.3 verlangt, dass, wenn ein Eingabefehler automatisch erkannt wird, das System eine Textbeschreibung bereitstellen muss, die vorschlägt, wie der Benutzer den Fehler korrigieren kann – es sei denn, dies würde die Sicherheit oder den Zweck gefährden. Dieses Kriterium ist entscheidend für Nutzer mit kognitiven Beeinträchtigungen, Screenreader-Nutzer und alle, die Schwierigkeiten haben, vage oder fehlende Fehlermeldungen zu verstehen.
WCAG 3.3.4 verlangt, dass Web-Eingaben, die rechtliche Verpflichtungen, finanzielle Transaktionen oder sensible Daten betreffen, vor der Finalisierung überprüft, korrigiert oder rückgängig gemacht werden können. Dies schützt alle Nutzer – insbesondere Menschen mit kognitiven und motorischen Beeinträchtigungen – vor irreversiblen Fehlern mit hohen Konsequenzen.
WCAG 3.3.8 verlangt, dass Authentifizierungsprozesse nicht auf Tests der kognitiven Fähigkeiten beruhen – wie das Merken von Passwörtern, das Lösen von Rätseln oder das Abschreiben von Zeichen –, es sei denn, es steht eine alternative Methode oder Unterstützung zur Verfügung. Dies schützt Nutzer mit kognitiven Beeinträchtigungen davor, von digitalen Diensten ausgeschlossen zu werden.
WCAG 4.1.3 verlangt, dass Statusmeldungen – wie Bestätigungen von Formularübermittlungen, Fehlermeldungen und Warenkorbaktualisierungen – programmatisch über Rolle oder Eigenschaft ermittelbar sind, damit unterstützende Technologien sie ankündigen können, ohne dass der Benutzer den Fokus verschieben muss. Dies stellt sicher, dass Nutzer, die auf Screenreader angewiesen sind, wichtige Rückmeldungen erhalten, selbst wenn der Fokus nicht auf die Meldung wechselt.
- Ich werde den ursprünglichen Sinn, Ton und Stil des Textes beibehalten. - Ich werde die formelle Anrede und den fachlichen Kontext korrekt ins Deutsche übertragen. - Ich werde alle Zahlen, Bezüge auf Richtlinien und Fachbegriffe exakt wiedergeben. - Ich werde die ursprünglichen Zeilenumbrüche und Absatzstruktur unverändert lassen. - Ich werde die Übersetzung kurz prüfen und bei Bedarf selbst korrigieren. WCAG 1.2.6 verlangt, dass für alle vorab aufgezeichneten Audioinhalte in synchronisierten Medien eine Gebärdensprachdolmetschung bereitgestellt wird. Dieses Kriterium stellt sicher, dass gehörlose Nutzer, deren primäre Sprache eine Gebärdensprache ist, vollständigen Zugang zu Audioinformationen haben, die möglicherweise nicht ausreichend allein durch Untertitel vermittelt werden können.
WCAG 1.2.7 verlangt, dass, wenn Pausen im Vordergrundaudio nicht ausreichen, um alle visuellen Informationen zu vermitteln, erweiterte Audiodeskriptionen – erreicht durch Anhalten des Videos – für vorab aufgezeichnete synchronisierte Medien bereitgestellt werden müssen. Dies stellt sicher, dass blinde und sehbehinderte Nutzer komplexe visuelle Inhalte vollständig verstehen können, die durch standardmäßige Audiodeskriptionen nicht abgedeckt werden können.
WCAG 1.2.8 verlangt, dass eine vollständige Textalternative für alle vorab aufgezeichneten synchronisierten Medien (Audio-Video) und vorab aufgezeichneten reinen Video-Inhalte bereitgestellt wird, um sicherzustellen, dass Nutzer, die Audio- oder visuelle Informationen nicht wahrnehmen können, auf den vollständigen Inhalt in Textform zugreifen können.
WCAG 1.2.9 verlangt, dass alle Live-Audioinhalte ohne Bild – wie Live-Rundfunksendungen oder reine Audiostreams – von einer gleichwertigen, in Echtzeit bereitgestellten Textalternative begleitet werden, etwa einem Live-Untertitelungsfeed oder einem Texttranskript, das synchron aktualisiert wird. Dies stellt sicher, dass Nutzerinnen und Nutzer, die taub oder schwerhörig sind, auf Live-Audioinhalte zugreifen können, ohne auf die Tonspur selbst angewiesen zu sein.
- Ich werde den ursprünglichen Sinn, Ton und Stil des Textes beibehalten. - Ich werde die formelle Anrede und den fachlichen Stil im Deutschen wahren. - Ich werde alle Zahlen, Sonderzeichen und Fachbegriffe korrekt übernehmen. - Ich werde die ursprünglichen Zeilenumbrüche und Absatzstruktur exakt erhalten. - Ich werde nach der Übersetzung kurz prüfen, ob Bedeutung und Stil korrekt wiedergegeben sind. WCAG 1.3.6 verlangt, dass der Zweck von Benutzeroberflächenkomponenten, Symbolen und Regionen programmatisch ermittelt werden kann, damit Browser und unterstützende Technologien die Darstellung anpassen können, um den Bedürfnissen einzelner Nutzer gerecht zu werden. Dieses Kriterium ist entscheidend für Nutzer mit kognitiven Beeinträchtigungen, die von personalisierten, vereinfachten oder mit Symbolen angereicherten Benutzeroberflächen profitieren.
WCAG 1.4.6 requires a minimum contrast ratio of 7:1 for normal text and 4.5:1 for large text between foreground and background colors, going beyond the AA threshold to ensure readability for users with low vision, color deficiencies, or those operating in challenging lighting conditions.
WCAG 1.4.7 requires that pre-recorded audio content containing speech either has no background sounds, allows background sounds to be turned off, or keeps background sounds at least 20 dB quieter than the foreground speech. This protects users with hearing loss and cognitive disabilities who struggle to separate speech from competing audio.
WCAG 1.4.8 requires that blocks of text be visually presented in ways users can control — covering foreground and background colors, line width, line spacing, and text alignment — so that people with reading, cognitive, or low-vision disabilities can comfortably read content without loss of information.
WCAG 1.4.9 requires that text be presented using actual text rather than images of text, with no exceptions beyond purely decorative content or cases where the specific visual presentation is essential to the information conveyed. This criterion ensures all users can adjust text rendering to suit their individual needs.
WCAG 2.1.3 requires that every function of a web page or application be operable via a keyboard interface, with no exceptions whatsoever—not even for path-dependent or freehand drawing tasks. This AAA criterion closes the loophole present in WCAG 2.1.1 and ensures full keyboard access for users who cannot use a mouse.
WCAG 2.2.3 (Level AAA) requires that timing is not an essential part of the event or activity presented by content, except for non-interactive synchronized media and real-time events. This ensures users with disabilities who need more time to read, interact, or respond are never excluded by time-dependent design.
WCAG 2.2.4 requires that users can postpone or suppress all interruptions — such as alerts, notifications, and automatic content updates — except those involving an emergency. This criterion is essential for users with attention, cognitive, or neurological disabilities who may be severely disrupted by unexpected interruptions during a task.
WCAG 2.2.5 requires that when an authenticated session expires, users can re-authenticate and continue their activity without losing any data they had entered. This criterion is critical for users with disabilities who may need more time to complete tasks and must not be penalized by session timeouts that erase their work.
WCAG 2.2.6 requires that users are warned about data loss due to inactivity timeouts, and that any such timeout lasts at least 20 hours unless the data is preserved. This protects users with cognitive disabilities, motor impairments, and others who need more time to complete tasks.
WCAG 2.3.2 requires that web pages contain no content that flashes more than three times in any one-second period, with no exception for small or low-contrast flashes. This stricter AAA criterion protects users with photosensitive epilepsy and other seizure disorders from potentially life-threatening neurological reactions.
WCAG 2.3.3 requires that motion animation triggered by user interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed. This matters because motion can trigger vestibular disorders, causing dizziness, nausea, and disorientation in a significant portion of the population.
WCAG 2.4.8 requires that users can determine where they are within a set of web pages — for example, through breadcrumbs, site maps, or highlighted navigation links. This helps users with cognitive disabilities, screen reader users, and anyone navigating complex sites to orient themselves and move through content with confidence.
WCAG 2.4.9 requires that the purpose of every link can be determined from the link text alone, without relying on surrounding context. This stricter AAA criterion ensures all users — especially screen reader users navigating by links — can understand where a link leads without reading the entire page.
WCAG 2.4.10 requires that section headings are used to organize content whenever a page contains multiple sections, enabling users to navigate and understand the structure of the page. This criterion supports screen reader users, cognitive accessibility needs, and anyone who relies on document structure to orient themselves within long or complex content.
WCAG 2.4.12 requires that when a UI component receives keyboard focus, no part of that component is hidden by author-created content — the focused element must be fully visible. This enhanced (AAA) criterion eliminates the partial-visibility allowance of its AA counterpart, ensuring keyboard users always see exactly where focus is.
WCAG 2.4.13 requires that keyboard focus indicators meet minimum size and contrast requirements so that users can clearly see which element has focus. This criterion ensures that people who rely on keyboards or assistive technologies can navigate interfaces without losing track of their current position.
WCAG 2.5.5 requires that interactive targets such as buttons and links be at least 44×44 CSS pixels in size, ensuring people with motor impairments, tremors, or limited dexterity can reliably activate controls without accidentally triggering adjacent elements.
WCAG 2.5.6 requires that web content does not restrict users to a single input modality when multiple input mechanisms are available on the platform, ensuring people can freely switch between touch, keyboard, mouse, voice, and other input methods without losing access to functionality.
WCAG 3.1.3 requires that websites provide a mechanism to identify the specific definition of words or phrases used in an unusual or restricted way, including idioms and jargon. This ensures that users with cognitive disabilities, non-native speakers, and those unfamiliar with specialized terminology can understand the content.
WCAG 3.1.4 verlangt, dass ein Mechanismus verfügbar ist, um die ausgeschriebene Form oder Bedeutung von im Inhalt verwendeten Abkürzungen zu identifizieren. Dieses Kriterium stellt sicher, dass Nutzer, die mit Abkürzungen, Akronymen oder Initialismen nicht vertraut sind, auf deren vollständige Bedeutung zugreifen können, was das Verständnis für Menschen mit kognitiven Beeinträchtigungen, Nicht-Muttersprachler und Screenreader-Nutzer unterstützt.
WCAG 3.1.5 verlangt, dass, wenn Inhalte eine Lesefähigkeit erfordern, die über das Niveau der unteren Sekundarstufe hinausgeht, eine ergänzende Version oder Zusammenfassung auf einem einfacheren Niveau bereitgestellt wird. Dies stellt sicher, dass Nutzer mit kognitiven Beeinträchtigungen, eingeschränkter Lese- und Schreibkompetenz oder Sprachbarrieren auf die Informationen zugreifen und sie verstehen können.
WCAG 3.1.6 verlangt, dass ein Mechanismus verfügbar ist, um die spezifische Aussprache von Wörtern zu identifizieren, deren Bedeutung ohne Kenntnis der Aussprache mehrdeutig ist. Dieses Kriterium stellt sicher, dass Nutzer, die auf Text-zu-Sprache-Technologie angewiesen sind oder auf eine ihnen unbekannte Sprache stoßen, auf die korrekte Bedeutung mehrdeutiger Inhalte zugreifen können.
WCAG 3.2.5 verlangt, dass Kontextänderungen – wie Seitenwechsel, Formularübermittlungen oder Inhaltsaktualisierungen – nur durch eine ausdrückliche Benutzeraktion ausgelöst werden und nicht automatisch. Dies schützt Nutzer, die auf Screenreader, Tastaturnavigation oder kognitive Unterstützungstools angewiesen sind, vor unerwarteten Unterbrechungen ihres Nutzungserlebnisses beim Surfen.
- Ich werde den ursprünglichen Sinn, Ton und Stil des Textes beibehalten. - Ich werde die formelle Anrede und den sachlichen Fachstil erhalten. - Ich werde alle Zahlen, Bezüge auf Normen und Fachbegriffe korrekt übertragen. - Ich werde Zeilenumbrüche und Absatzstruktur exakt beibehalten. - Ich werde Eigennamen und Standards (z. B. WCAG) unverändert lassen. - Ich werde die Übersetzung kurz prüfen und bei Bedarf korrigieren. WCAG 3.3.5 verlangt, dass kontextsensitive Hilfe verfügbar ist, wenn eine Webseite Benutzereingaben anfordert, damit Nutzer verstehen können, welche Informationen erforderlich sind und wie sie diese korrekt bereitstellen. Dieses Kriterium reduziert Fehler und unterstützt Nutzer mit kognitiven Beeinträchtigungen, unerfahrene Nutzer und alle, die komplexe Formulare ausfüllen.
WCAG 3.3.6 verlangt, dass bei jeder Webseite, die eine Nutzereingabe erfordert, Eingaben entweder rückgängig gemacht werden können, auf Fehler überprüft werden und Korrekturhinweise enthalten oder vor der endgültigen Übermittlung bestätigt werden können. Dieses AAA-Kriterium erweitert 3.3.4 auf alle Formulare – nicht nur auf rechtliche oder finanzielle – und schützt Nutzer in jeder Interaktion vor irreversiblen Fehlern.
WCAG 3.3.9 verlangt, dass Authentifizierungsprozesse keinerlei kognitive Funktionstests beinhalten – keine Rätsel, kein Auswendiglernen und keine Abschrift –, es sei denn, eine nicht-kognitive Alternative, ein unterstützender Mechanismus oder eine objektbasierte Methode ist verfügbar. Dieses erweiterte (AAA) Kriterium beseitigt die letzten Barrieren bei der Authentifizierung für Nutzer mit kognitiven, motorischen und gedächtnisbezogenen Beeinträchtigungen.
WCAG 4.1.1 Parsing verlangt, dass Webinhalte frei von schwerwiegenden HTML/XML-Fehlern sind – wie etwa doppelten IDs –, die dazu führen könnten, dass unterstützende Technologien die Seite falsch interpretieren oder nicht verarbeiten können. Obwohl dieses Kriterium in WCAG 2.2 als veraltet gilt, bleiben die zugrunde liegenden axe-core-Regeln aktiv, und Verstöße weisen weiterhin auf ein reales Barrierefreiheitsrisiko hin.
Präsidialerlass 2025/10, veröffentlicht im Amtsblatt der Republik Türkei Nr. 32933 am 21. Juni 2025, schreibt eine an WCAG 2.2 ausgerichtete Barrierefreiheit für Websites und mobile Anwendungen in einem breiten Spektrum von Organisationen des öffentlichen und privaten Sektors vor, mit Umsetzungsfristen von einem Jahr für den öffentlichen Sektor und zwei Jahren für E-Commerce-Anbieter.
Dieser Artikel erläutert das Programm für das Barrierefreiheitslogo der Türkei, das mit dem Präsidialrundschreiben 2025/10 (Amtsblatt Nr. 32933, 21. Juni 2025) eingeführt wurde, und behandelt, wer verpflichtet ist, die technischen Anforderungen von WCAG 2.2, das auf Überwachung basierende Vergabeverfahren sowie praktische Schritte zur Erreichung der Konformität.
Dieser Artikel erläutert, wie verpflichtete Organisationen in Türkiye gemäß Präsidialerlass Nr. 2025/10 eine interne Kommission zur Überprüfung der Barrierefreiheit von Websites und mobilen Anwendungen (İnceleme Komisyonu) einrichten müssen, einschließlich der rechtlichen Grundlage, der Verpflichtungen, der Anforderungen der WCAG 2.2 und einer schrittweisen Umsetzungshilfe.
