Accessibility
80 Beiträge
WCAG 1.1.1: Nicht-textueller Inhalt
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: Nur Audio und nur Video (vorab aufgezeichnet)
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: Untertitel (voraufgezeichnet)
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: Audiodeskription oder Medienalternative (aufgezeichnet)
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: Informationen und Beziehungen
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: Bedeutungsvolle Reihenfolge
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: Sensorische Merkmale
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: Verwendung von Farbe
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: Audiosteuerung
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: Tastatur
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: Keine Tastaturfalle
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: Tastenkombinationen mit einzelnen Zeichen
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.
WCAG 2.2.1: Zeitlich anpassbar
- 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.
WCAG 2.2.2: Pause, Stopp, Ausblenden
- 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: Drei Blitze oder unterhalb des Schwellenwerts
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: Blöcke überspringen
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: Seite betitelt
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: Fokusreihenfolge
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: Zweck des Links (im Kontext)
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: Zeigergesten
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: Zeigerabbruch
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.4: Bewegungsaktivierung
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: Sprache der Seite
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: Beim Fokus
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: Bei Eingabe
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: Fehlererkennung
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: Beschriftungen oder Anweisungen
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: Redundante Eingabe
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: Name, Rolle, Wert
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.3.4: Ausrichtung
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: Eingabezweck identifizieren
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: Kontrast (Minimum)
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: Text vergrößern
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: Bilder von Text
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: Umfluss
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: Nicht-Text-Kontrast
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: Textabstand
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: Inhalt bei Hover oder Fokus
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: Mehrere Wege
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: Überschriften und Beschriftungen
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: Fokus sichtbar
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: Fokus nicht verdeckt (Minimum)
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: Ziehbewegungen
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: Zielgröße (Minimum)
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: Sprache von Teilen
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.
WCAG 3.2.3: Konsistente Navigation
- 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: Konsistente Identifizierung
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: Konsistente Hilfe
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: Fehlervorschlag
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: Fehlervermeidung (Rechtliches, Finanzielles, Daten)
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: Barrierefreie Authentifizierung (Minimum)
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: Statusmeldungen
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.
WCAG 1.2.6: Gebärdensprache (aufgezeichnet)
- 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: Erweiterte Audiodeskription (aufgezeichnet)
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: Medienalternative (voraufgezeichnet)
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: Nur Audio (Live)
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.
WCAG 1.4.6: Kontrast (erweitert)
WCAG 1.4.6 verlangt ein minimales Kontrastverhältnis von 7:1 für normalen Text und 4,5:1 für großen Text zwischen Vorder- und Hintergrundfarben und geht damit über den AA-Grenzwert hinaus, um die Lesbarkeit für Nutzer mit Sehbeeinträchtigungen, Farbsehschwächen oder solche in schwierigen Lichtverhältnissen sicherzustellen.
WCAG 1.4.7: Geringe oder keine Hintergrundgeräusche
WCAG 1.4.7 verlangt, dass vorab aufgezeichnete Audioinhalte, die Sprache enthalten, entweder keine Hintergrundgeräusche haben, das Ausschalten der Hintergrundgeräusche ermöglichen oder die Hintergrundgeräusche mindestens 20 dB leiser halten als die Sprache im Vordergrund. Dies schützt Nutzer mit Hörverlust und kognitiven Beeinträchtigungen, die Schwierigkeiten haben, Sprache von konkurrierenden Audiosignalen zu unterscheiden.
WCAG 1.4.8: Visuelle Darstellung
WCAG 1.4.8 verlangt, dass Textblöcke visuell so dargestellt werden, dass Nutzer sie steuern können – einschließlich Vorder- und Hintergrundfarben, Zeilenbreite, Zeilenabstand und Textausrichtung –, damit Menschen mit Lese-, kognitiven oder Sehbehinderungen Inhalte komfortabel lesen können, ohne dass Informationen verloren gehen.
WCAG 1.4.9: Bilder von Text (ohne Ausnahme)
WCAG 1.4.9 verlangt, dass Text mithilfe von tatsächlichem Text und nicht als Textbilder dargestellt wird, ohne Ausnahmen über rein dekorative Inhalte hinaus oder Fälle, in denen die spezifische visuelle Darstellung für die vermittelte Information wesentlich ist. Dieses Kriterium stellt sicher, dass alle Nutzer die Textdarstellung an ihre individuellen Bedürfnisse anpassen können.
WCAG 2.1.3: Tastatur (ohne Ausnahme)
WCAG 2.1.3 verlangt, dass jede Funktion einer Webseite oder Anwendung über eine Tastaturschnittstelle bedienbar ist, ohne jegliche Ausnahmen – nicht einmal für pfadabhängige oder freihändige Zeichenaufgaben. Dieses AAA-Kriterium schließt die in WCAG 2.1.1 vorhandene Lücke und stellt vollständigen Tastaturzugang für Nutzer sicher, die keine Maus verwenden können.
WCAG 2.2.3: Keine Zeitvorgaben
WCAG 2.2.3 (Level AAA) verlangt, dass Zeitvorgaben kein wesentlicher Bestandteil des durch Inhalte dargestellten Ereignisses oder der Aktivität sind, mit Ausnahme von nicht-interaktiven synchronisierten Medien und Echtzeitereignissen. Dies stellt sicher, dass Nutzer mit Behinderungen, die mehr Zeit zum Lesen, Interagieren oder Reagieren benötigen, niemals durch zeitabhängiges Design ausgeschlossen werden.
WCAG 2.2.4: Unterbrechungen
WCAG 2.2.4 verlangt, dass Nutzer alle Unterbrechungen – wie Warnmeldungen, Benachrichtigungen und automatische Inhaltsaktualisierungen – aufschieben oder unterdrücken können, mit Ausnahme solcher, die einen Notfall betreffen. Dieses Kriterium ist entscheidend für Nutzer mit Aufmerksamkeits-, kognitiven oder neurologischen Beeinträchtigungen, die durch unerwartete Unterbrechungen während einer Aufgabe stark beeinträchtigt werden können.
WCAG 2.2.5: Erneute Authentifizierung
WCAG 2.2.5 verlangt, dass Benutzer nach Ablauf einer authentifizierten Sitzung sich erneut authentifizieren und ihre Tätigkeit fortsetzen können, ohne dabei Daten zu verlieren, die sie eingegeben haben. Dieses Kriterium ist entscheidend für Nutzer mit Behinderungen, die möglicherweise mehr Zeit benötigen, um Aufgaben zu erledigen, und nicht durch Sitzungs-Timeouts bestraft werden dürfen, die ihre Arbeit löschen.
WCAG 2.2.6: Zeitüberschreitungen
WCAG 2.2.6 verlangt, dass Nutzer vor Datenverlust durch Inaktivitäts-Timeouts gewarnt werden und dass ein solches Timeout mindestens 20 Stunden dauert, sofern die Daten nicht erhalten bleiben. Dies schützt Nutzer mit kognitiven Beeinträchtigungen, motorischen Einschränkungen und andere, die mehr Zeit benötigen, um Aufgaben zu erledigen.
WCAG 2.3.2: Drei Blitze
WCAG 2.3.2 verlangt, dass Webseiten keinerlei Inhalte enthalten, die mehr als dreimal innerhalb eines Zeitraums von einer Sekunde blinken, ohne Ausnahme für kleine oder kontrastarme Blitze. Dieses strengere AAA-Kriterium schützt Nutzer mit fotosensitiver Epilepsie und anderen Anfallsleiden vor potenziell lebensbedrohlichen neurologischen Reaktionen.
WCAG 2.3.3: Animationen aus Interaktionen
WCAG 2.3.3 verlangt, dass durch Benutzerinteraktion ausgelöste Bewegungsanimationen deaktiviert werden können, es sei denn, die Animation ist für die Funktionalität oder die zu vermittelnden Informationen wesentlich. Dies ist wichtig, weil Bewegung vestibuläre Störungen auslösen kann, die bei einem erheblichen Teil der Bevölkerung Schwindel, Übelkeit und Desorientierung verursachen.
WCAG 2.4.8: Standort
WCAG 2.4.8 verlangt, dass Nutzerinnen und Nutzer erkennen können, wo sie sich innerhalb einer Gruppe von Webseiten befinden – zum Beispiel durch Breadcrumbs, Sitemaps oder hervorgehobene Navigationslinks. Dies hilft Menschen mit kognitiven Beeinträchtigungen, Screenreader-Nutzenden und allen, die komplexe Websites navigieren, sich zu orientieren und sich selbstbewusst durch Inhalte zu bewegen.
WCAG 2.4.10: Abschnittsüberschriften
WCAG 2.4.10 verlangt, dass Abschnittsüberschriften verwendet werden, um Inhalte zu organisieren, wann immer eine Seite mehrere Abschnitte enthält, sodass Nutzer die Struktur der Seite navigieren und verstehen können. Dieses Kriterium unterstützt Screenreader-Nutzer, kognitive Barrierefreiheitsbedürfnisse und alle, die auf die Dokumentstruktur angewiesen sind, um sich in langen oder komplexen Inhalten zu orientieren.
WCAG 2.4.12: Fokus nicht verdeckt (erweitert)
WCAG 2.4.12 verlangt, dass, wenn eine UI-Komponente den Tastaturfokus erhält, kein Teil dieser Komponente durch vom Autor erstellte Inhalte verdeckt wird – das fokussierte Element muss vollständig sichtbar sein. Dieses erweiterte (AAA-)Kriterium beseitigt die teilweise Sichtbarkeitszulassung seines AA-Gegenstücks und stellt sicher, dass Tastaturnutzende immer genau sehen, wo sich der Fokus befindet.
WCAG 2.4.13: Fokusdarstellung
WCAG 2.4.13 verlangt, dass Tastatur-Fokusindikatoren Mindestanforderungen an Größe und Kontrast erfüllen, damit Nutzer klar erkennen können, welches Element den Fokus hat. Dieses Kriterium stellt sicher, dass Menschen, die auf Tastaturen oder unterstützende Technologien angewiesen sind, in Benutzeroberflächen navigieren können, ohne ihre aktuelle Position aus den Augen zu verlieren.
WCAG 2.5.5: Zielgröße (erweitert)
WCAG 2.5.5 verlangt, dass interaktive Ziele wie Schaltflächen und Links mindestens 44×44 CSS-Pixel groß sind, damit Menschen mit motorischen Beeinträchtigungen, Tremor oder eingeschränkter Geschicklichkeit Steuerelemente zuverlässig aktivieren können, ohne versehentlich benachbarte Elemente auszulösen.
WCAG 3.1.3: Ungewöhnliche Wörter
WCAG 3.1.3 verlangt, dass Websites eine Möglichkeit bereitstellen, die spezifische Definition von Wörtern oder Ausdrücken zu ermitteln, die in einer ungewöhnlichen oder eingeschränkten Weise verwendet werden, einschließlich Redewendungen und Fachjargon. Dies stellt sicher, dass Nutzer mit kognitiven Beeinträchtigungen, Nicht-Muttersprachler und Personen, die mit spezialisierter Terminologie nicht vertraut sind, den Inhalt verstehen können.
WCAG 3.1.4: Abkürzungen
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: Lesestufe
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: Aussprache
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: Änderung auf Anfrage
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.
WCAG 3.3.6: Fehlervermeidung (Alle)
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: Barrierefreie Authentifizierung (Erweitert)
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 (Veraltet in WCAG 2.2)
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.