Prüfkriterien für digitale Barrierefreiheit (WCAG 2.2 + BITV 2.0)

Ist das Bild nur dekorativ, spar dir den Alt-Text definitiv!

Bilder, die rein visuellen Mehrwert liefern und keine wichtigen Informationen vermitteln, brauchen keine Textalternative. Sie müssen auch vor assistiven Technologien versteckt werden. Bei <img>: Das Alt-Attribut leer lassen. Bei <svg>: aria-hidden nutzen.

Ich kann das Bild nicht sehen, drum schreib mir Text, ums zu verstehen!

Bilder und Grafiken, die wichtige Infos vermitteln, brauchen eine Textalternative. Diese kann im Alt-Attribut oder auch als Text neben dem Bild stehen. Zu wichtigen Infos zählen auch Bilder, die Emotionen vermitteln.

Hat das Icon einen Link, gib mir einen Wink!

Grafische Bedienelemente, wie klickbare Icons oder klickbare Bilder, benötigen einen Namen, damit auch Screenreader-User die Funktion der Grafik verstehen. Das geht zum Beispiel mit Text im Alt-Attribut oder einem aria-label.

Grafische CAPTCHAS? Dann bitte nicht nur eins – entweder mit Alternative, oder keins!

CAPTCHAs brauchen Alternativen. Ein Audio-CAPTCHA braucht ein Bild-CAPTCHA als Alternative und umgekehrt. Bildbasierte CAPTCHAs brauchen auch einen Text im Alt-Attribut, der den Zweck des CAPTCHAs beschreibt.

Stecken in Audios und Videos wichtige Information, lohnt sich eine Alternative schon!

Audiodateien brauchen eine Alternative in Form von Text. Stumme Videos können als Alternative eine Beschreibung der Inhalte in Textform oder in Form einer Audiodatei haben.

Ein Untertitel fürs Video macht dich und deine Umgebung froh!

Aufgezeichnete Videos benötigen synchrone Untertitel. Zu einem vollständigen Untertitel gehören nicht nur gesprochene Worte, sondern auch die Namen der Sprecher, menschliche Laute und wichtige Geräusche wie Musik.

Hast du Audiodeskription oder Volltext als Alternative, unterstelle ich dir edle Motive!

Deine Videos benötigen eine Audiodeskription oder Volltext-Alternative, wenn wichtiger Inhalt darin vorkommt, der nicht auf der Tonspur beschrieben wird.

Machst du deinen Live-Vortrag, sind Untertitel, was ich mag!

Live-Übertragungen brauchen synchrone Untertitel. Dabei sollten nicht nur der Inhalt wiedergegeben werden, sondern auch, wer gerade spricht und welche wichtigen Geräusche zu hören sind.

Zeigen Bilder in Videos wichtige Information, brauchst du Audiodeskription!

Wenn ein Video wichtige Infos nur visuell, aber nicht über Ton vermittelt, braucht es eine Audiodeskription. So ein Inhalt kann schon der Name des Sprechers sein, wenn er nur im Bild gezeigt, aber nicht gesagt wird.

Standard-Kriterium der WCAG.

Dieses Kriterium (Sign Language (Prerecorded)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Extended Audio Description (Prerecorded)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Media Alternative (Prerecorded)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Audio-only (Live)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Zeigst du eine Liste, nutze »ul« oder »ol« für die Kiste!

Inhalte, die optisch wie Listen aussehen, müssen im HTML auch als Listen ausgezeichnet sein. Dafür kannst du entweder <ul>, <ol> oder <dl> nutzen, je nachdem, wofür die Liste gedacht ist.

Sei ein Held und verknüpfe Labels per Code mit dem Formularfeld.

Formulare müssen so aufgebaut sein, dass ihre Struktur und Zusammenhänge auch im Code richtig hinterlegt sind. Dazu gehört, dass jedes Feld einen verständlichen Namen hat und Gruppen von Feldern programmatisch als Einheit ausgezeichnet werden.

Gib Absätzen ein »p«, sowie »strong« und »em«, damit ichs seh!

Für Absätze und formatierte Texte (fett oder kursiv) müssen die richtigen HTML-Tags verwendet werden. Im Fließtext dürfen keine Abstände mit doppelten Zeilenumbrüchen (<br><br>) erzeugt werden.

Nutzt du Tabellen für dein Layout, habe keine Strukturelemente verbaut!

Wenn eine Webseite HTML-Tabellen für das Layout benutzt, dürfen diese keine Semantik (<table>, <th>, <td>) haben, damit Screenreader sie nicht als Tabellen auslesen.

Informationen, die visuell in Tabellenform dargestellt werden, müssen auch im HTML als Tabelle ausgezeichnet sein. So können assistive Technologien die Inhalte richtig auslesen.

Stellst du auf der Seite Tabellen dar, mache den Bezug von Überschrift zu Inhalt klar.

Die Header von Tabellen müssen als <th> und die Inhalte als <td> ausgezeichnet werden. Bei komplexen Tabellen mit mehreren Headern brauchst du außerdem das »scope«-Attribut, um die Zusammenhänge klarzumachen.

Bleibe wirklich stur, bei der Überschriften-Struktur!

Überschriften müssen auch im HTML als solche ausgezeichnet sein (<h1> bis <h6>) und sollten in der richtigen Reihenfolge stehen – also zum Beispiel keine <h5> direkt nach einer <h2>.

Zitierst du mich, so vergiss die Blockquote nicht!

Alleinstehende Zitate müssen als <blockquote> ausgezeichnet sein. Das können etwa Feedbacks von Kund*innen sein, die einzeln auf der Webseite stehen. Im Fließtext braucht ein Zitat dagegen nicht unbedingt eine Auszeichnung.

Beeinflusst die Reihenfolge der Elemente den Sinn, kriegen das assistive Technologien auch hin?

Die visuelle Anordnung (z. B. mit CSS-Grids) darf die logische Reihenfolge von Inhalten nicht beeinflussen. Zusammengehörende Elemente, wie eine Überschrift und ein Text, müssen auch so von Screenreadern gelesen werden können.

Beschreibst du Inhalte jeglicher Sorte, nutze nicht nur »grün, eckig« oder andere sensorische Worte.

Verzichte auf sensorische Hinweise in deinen Texten. “Unten Links” kann ein Screenreader-User oft nicht finden, aber den Text eines Buttons oder Labels schon. Schreibe also eher: “Klicke auf den Button ‘Jetzt kaufen’!”

Lass User ihren Bildschirm drehen, sonst ist’s um die Nutzbarkeit geschehen.

Man muss eine Website sowohl im Hoch- als auch im Querformat anschauen können. Das Wechseln des Formats darf nicht blockiert werden.

Um Formulare automatisch zu befüllen, zeige mir den Zweck, um die Aufgabe zu erfüllen

Wenn User persönliche Daten (Name, Adresse, Passwort) eingeben müssen, brauchen die Formularfelder ein autocomplete-Attribut mit den richtigen Werten. Beispiel für den Namen: autocomplete=”given-name”

Standard-Kriterium der WCAG.

Dieses Kriterium (Identify Purpose) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Muss ich Informationen verstehen, sollte das nicht nur durch Farbe gehen.

Eine Website muss auch für Menschen mit Farbsehschwäche funktionieren. Wird etwas nur über Farbe vermittelt? (Beispiel: grüner Punkt = aktiv, rot = inaktiv). Dann braucht es zusätzliche grafische Elemente oder Text.

Geht der Ton per Knopfdruck nicht aus, bin ich auch schon direkt raus!

Wenn deine Website automatisch Ton abspielt, der länger als drei Sekunden dauert, musst du eine Möglichkeit bieten, den Ton abzuschalten.

Kann ich Farben nicht gut erkennen, werde ich mich von deiner Seite trennen.

Alle Texte (Fließtext, Labels, Placeholder usw.) brauchen das richtige Kontrastverhältnis zum Hintergrund. Der Mindestkontrast liegt bei 4,5:1 für Texte unter 24 Pixel und bei 3:1 für Texte über 24 Pixel.

Für manche ist dein Text zu klein, darum muss das Zoomen sein.

Eine Webseite muss auf 200 % vergrößert werden können, ohne dass dabei Texte oder andere Inhalte verdeckt werden oder ganz verschwinden. Alle wichtigen Funktionen der Webseite müssen weiterhin bedienbar bleiben.

Zeigst du wichtigen Text im Bild, dann ist das für mich zu wild!

Schreibe wichtige Infos nicht (nur) als Text in Pixelgrafiken. User können diese Texte nicht nach ihren Bedürfnissen anpassen, und auch assistive Technologien können sie nicht auslesen.

Standard-Kriterium der WCAG.

Dieses Kriterium (Contrast (Enhanced)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Low or No Background Audio) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Visual Presentation) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Images of Text (No Exception)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Zoome ich auch 400 % hinein, müssen deine Inhalte trotzdem lesbar sein!

Deine Website muss auch bei 320 px Breite (oder 400 % Zoom bei 1280 px) so funktionieren, dass alle Inhalte und Funktionalitäten erhalten bleiben und Texte nicht horizontal und vertikal gescrollt werden müssen.

Brauch ich das Element, um den Inhalt zu verstehen, ist es wichtig, es gut zu sehen!

Alle grafischen Elemente, mit denen man interagieren kann (zum Beispiel Icon-Buttons) oder die fürs Verständnis wichtig sind, brauchen einen Mindestkontrast von 3:1 zum Hintergrund.

Entscheiden sich Nutzer für mehr Zeilenabstand, schneide ihnen die Texte nicht ab, am Rand!

Wenn User den Zeilen- oder Buchstabenabstand von Texten vergrößern, dürfen die Texte nicht abgeschnitten oder verdeckt werden.

Blendest du zusätzlich Inhalte ein, lass sie auch bedienbar sein!

Elemente, die per Fokus oder Hover eingeblendet werden (wie Untermenüs), sollten per ESC-Taste zu schließen sein. Außerdem dürfen sie sich weder von selbst wieder schließen noch während man mit der Maus über sie fährt.

Schließ mich nicht aus, nutze ich keine Maus!

Eine Website muss komplett mit der Tastatur bedienbar sein. Dabei muss man alle Inhalte erreichen können, und alle wichtigen Funktionen müssen ausgeführt werden können.

Tu mir einen großen Gefallen, stell mir keine Tastaturfallen!

Wenn ein Element den Fokus über die Tastatur erhalten kann, muss es auch möglich sein, den Fokus per Tastatur wieder wegzubewegen. Man muss also mit der Tab-Taste, den Pfeiltasten, ESC oder Enter das Element wieder verlassen können.

Standard-Kriterium der WCAG.

Dieses Kriterium (Keyboard (No Exception)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Hast du Tastatur-Kurzbefehle auf der Seite? Mach sie abschaltbar, sonst such ich das Weite.

Wenn deine Website einzelne Zeichen (Buchstaben, Ziffern, Sonderzeichen) mit Funktionen belegt, sollten diese Tastenkürzel anpassbar oder abschaltbar sein.

Gib mir genug Zeit, sonst tut es dir noch leid!

Zeitliche Begrenzungen auf einer Seite müssen abschaltbar oder verlängerbar sein. Man darf User also nicht einfach ausloggen, ohne sie zu warnen oder ihnen zu ermöglichen, die Zeit zu verlängern.

Willst du Elemente bewegen? Bei unter 5 Sekunden, hast du meinen Segen.

Animationen, die auf deiner Website automatisch starten und länger als 5 Sekunden dauern, müssen pausiert, gestoppt oder ausgeblendet werden können.

Standard-Kriterium der WCAG.

Dieses Kriterium (No Timing) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Interruptions) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Re-authenticating) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Timeouts) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Blitzt ein Element häufiger als dreimal auf, nehme ich das nicht mehr in Kauf!

Deine Website darf keine Elemente enthalten, die größer als 148 × 148 Pixel (Richtwert) sind und öfter als dreimal pro Sekunde aufblitzen. Dazu gehören zum Beispiel blinkende GIFs oder flackernde Sequenzen in Videos.

Standard-Kriterium der WCAG.

Dieses Kriterium (Three Flashes) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Bewegung durch Interaktion muss abschaltbar sein, damit mir nicht schwindelig wird!

Bewegungsanimationen, die durch Benutzerinteraktionen ausgelöst werden (z.B. Parallax-Scrolling, Zoom-Effekte), müssen deaktivierbar sein. Menschen mit vestibulären Störungen können durch solche Animationen Schwindel, Übelkeit oder Desorientierung erleben. Die Systemeinstellung 'Reduzierte Bewegung' (prefers-reduced-motion) sollte respektiert werden.

Kann ich mit assistiver Technologie Bereiche überspringen, wird mir die Navigation gelingen!

Auf einer Website muss es möglich sein, wiederholende Bereiche (wie Header und Footer) zu überspringen. Nutze dafür am besten versteckte Sprunglinks oder HTML-Landmarks.

Schreibe den Titel jeder Seite gut, dann weiß ich, was die Seite tut.

Jede Unterseite muss einen sinnvollen HTML-Titel haben, damit man sie im Browser leicht finden kann. Der Titel sollte den »Namen der aktuellen Seite« plus den »Namen der ganzen Webseite« enthalten.

Geh ich mit der Tastatur in deine Webseite rein, sollte die Reihenfolge logisch sein.

Mit der Tastatur (Tab-Taste) muss man die Inhalte deiner Website in einer sinnvollen Reihenfolge ansteuern können. Normalerweise folgt die Tab-Reihenfolge der visuellen Reihenfolge.

Nutzt du nur Linktexte, wie „Mehr Lesen“ oder „Hier klicken“, werde ich dich gehörig anzicken!

Die Texte von Links sollten alleine aussagekräftig sein. Ein Link darf vage sein („Mehr erfahren“), wenn der Kontext das Ziel klarmacht. Als Kontext zählt zum Beispiel eine vorhergehende Überschrift oder ein <p>-Tag um den Link herum.

Zusätzlich zur Navigation, wird sich eine Suche oder Sitemap lohn.

Die Unterseiten deiner Website müssen auf mehr als einem Weg erreichbar sein. Zusätzlich zur Navigation solltest du zum Beispiel eine Suche oder eine Sitemap anbieten.

Ich komme mir vor, als stehe ich im Wald, beschreiben deine Überschriften nicht den Inhalt.

Überschriften müssen den Inhalt oder den Zweck des Inhalts, der auf sie folgt, klar beschreiben. Auch die Beschriftungen von Formularfeldern müssen deutlich machen, was man in das Feld eintragen soll.

Zeig mir einen Rahmen an, damit ich den Tastaturfokus erkennen kann.

Interaktive Elemente (Buttons, Links usw.) brauchen einen Fokuszustand. Es muss immer sichtbar sein, welches Element auf der Seite den Tastaturfokus hat.

Standard-Kriterium der WCAG.

Dieses Kriterium (Location) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Link Purpose (Link Only)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Section Headings) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Sei nicht gemein, lass den Fokus nicht verdeckt sein!

Interaktive Elemente dürfen, wenn sie per Tastatur fokussiert sind, nicht vollständig von anderen Inhalten verdeckt werden. Sticky-Header, aufklappbare Menüs oder Dialoge dürfen zum Beispiel keine fokussierten Elemente überdecken.

Standard-Kriterium der WCAG.

Dieses Kriterium (Focus Not Obscured (Enhanced)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Focus Appearance) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Wenn der User drücken und ziehen kann, biete alternative Möglichkeiten an.

Jede Funktion einer Website muss per einfacher Eingabe zu bedienen sein. Komplexere Gesten wie Swipen oder Aktionen mit mehreren Fingern brauchen eine »klickbare« Alternative (Maus, Touch, Enter).

Mit dem Finger drücken und halten, sollt keine Konsequenzen entfalten!

Das Drücken und Halten eines Buttons oder Links (mit Maus oder Finger) darf nicht direkt eine Aktion auslösen. Erst das Loslassen darf die Aktion ausführen, damit sie noch abgebrochen werden kann.

Halte deine Beschriftungen gleich, im sichtbaren und im versteckten Bereich.

Wenn du versteckte Texte nutzt, um Links, Buttons oder Formularfelder für Screenreader genauer zu beschreiben, muss der sichtbare Text zumindest im versteckten Text enthalten sein. Am besten startet er auch genau so.

Muss ich mein Handy schütteln, ist an Alternativen nichts zu rütteln.

Funktionen, die durch die Bewegung eines Geräts ausgelöst werden, müssen auch über eine einfache Eingabe (Maus, Touch, Enter) auslösbar sein. Zudem muss die Aktivierung durch Bewegung abgeschaltet werden können.

Standard-Kriterium der WCAG.

Dieses Kriterium (Target Size (Enhanced)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Concurrent Input Mechanisms) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Muss ein User Dinge ziehen, gib ihm Alternativen, sonst wird dir nicht verziehen.

Wenn es Funktionen auf der Website gibt, die nur über Drag-and-drop-Gesten ausgelöst werden, müssen diese eine einfache Eingabe als Alternative haben. Dazu zählt zum Beispiel das Klicken eines Buttons.

Soll es gut bedienbar sein, mach die Dinge nicht zu klein!

Bedienelemente wie Buttons oder Links müssen eine klickbare Fläche von mindestens 24 × 24 px haben, die sich nicht mit der klickbaren Fläche anderer bedienbarer Elemente überschneidet.

Willst du, dass ich dich lesen kann, zeig mir deine Sprache an.

Der <html>-Tag muss ein »lang«-Attribut mit der Sprache der Seite haben. So können assistive Technologien die Seite in der richtigen Sprache wiedergeben, und auch die automatische Übersetzung im Browser funktioniert richtig.

Nutzt du andere Sprache in deinen Sätzen, musst du ein Lang-Attribut setzen.

Wenn auf einer Website Sätze, Phrasen, Zitate oder Ähnliches in einer anderen Sprache verwendet werden, muss der anderssprachige Text mit dem »lang«-Attribut und der richtigen Sprache ausgezeichnet werden.

Standard-Kriterium der WCAG.

Dieses Kriterium (Unusual Words) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Abbreviations) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Reading Level) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Pronunciation) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Nur weil ich etwas fokussiere, heißt es nicht, dass was passiere!

Den Tastaturfokus auf ein Element zu setzen, darf keine Funktion auslösen, die den Kontext verändert. Funktionen sollen erst bei Bestätigung, zum Beispiel per Enter, Leertaste oder Mausklick ausgeführt werden.

Löst meine Eingabe Kontextänderungen aus, macht sie die Seite zu einem Graus!

Das Interagieren mit einem Formularelement (z. B. Checkbox) darf keine unerwartete Kontextänderung, wie eine Verschiebung des Tastaturfokus, auslösen. Eine Kontextänderung ist erlaubt, wenn der User vorher gewarnt wurde.

Halte die Navigation konsistent, damit der User sie wiedererkennt.

Die Navigations-Mechanismen (Menü, Breadcrumbs, Suche und Ähnliches) auf deiner Website müssen immer an der gleichen Stelle zu finden sein, damit die Navigation durch die Unterseiten einfacher wird.

Wer ‚A‘ sagt, muss auch immer ‚A‘ sagen!

Die Benennung von Bedienelementen (wie Links, Buttons, Formularfelder) muss einheitlich sein, wenn sie auf mehreren Unterseiten die gleiche Funktion haben. Das sollte auch fürs Aussehen gelten.

Standard-Kriterium der WCAG.

Dieses Kriterium (Change on Request) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Unterstützung und Support gehören immer an denselben Ort.

Wenn eine Website eine Hilfe anbietet, sollte diese leicht und schnell zu finden sein. Achte darauf, dass sie auf allen Unterseiten immer an derselben Stelle platziert ist. Als Hilfe zählt zum Beispiel schon die Angabe einfacher Kontaktdaten.

Um Fehler wirklich zu verstehen, sollte ich Texte dazu sehen!

Wenn ein Eingabefehler in einem Formular auftritt, muss der Fehler dem User in Textform beschrieben werden.

Gib Formularfeldern Beschreibungen oder Namen, um sie als User zu erahnen.

Formularfelder sollten sichtbare Beschriftungen haben, am besten über das <label>-Tag. Die Beschriftung sollte dauerhaft sichtbar sein.

Zeigst du mir im Formular Fehler an, häng ein Lösungshinweis mit dran.

Die Texte einer Fehlermeldung sollten möglichst konkret sein, damit man auch weiß, wie der Fehler behoben werden kann.

Bestätigen, rückgängig machen und korrigieren, sollte bei wichtigen Daten funktionieren.

Bei einer Transaktion oder Interaktion, die negative Folgen haben kann, sollte es möglich sein, die Aktion entweder vor dem Absenden zu prüfen, sie noch einmal zu bestätigen oder sie rückgängig zu machen.

Standard-Kriterium der WCAG.

Dieses Kriterium (Help) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Error Prevention (All)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Hab ich’s schon mal eingetragen, musst du's mich nicht noch mal fragen.

User sollten Daten nur einmal eingeben müssen. Werden die Daten erneut gebraucht? Dann sollte die Website sie automatisch ausfüllen oder es ermöglichen, sie einfach zu übernehmen (Beispiel: Lieferdaten = Rechnungsdaten).

Log-in bitte nur ohne Denken, um meine Zeit nicht zu verschenken.

Wenn User ihre Identität bestätigen müssen, darf das keinen kognitiven Funktionstest erfordern. Copy-and-paste oder das Ausfüllen über einen Passwort-Manager sollte problemlos möglich sein.

Standard-Kriterium der WCAG.

Dieses Kriterium (Accessible Authentication (Enhanced)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Standard-Kriterium der WCAG.

Dieses Kriterium (Parsing (Obsolete and removed)) ist Teil der offiziellen WCAG-Spezifikation, wurde aber in der vereinfachten Liste nicht explizit aufgeführt.

Stellst du programmierte Komponenten bereit, sorge für eine gute Bedienbarkeit.

Alle interaktiven Elemente auf einer Website müssen so programmiert sein, dass Name, Rolle und Wert (oder Zustand) von assistiven Technologien ermittelt werden können und auch Änderungen aktualisiert werden.

Willst du ein reines Gewissen, lass mich von Veränderungen automatisch wissen!

Wenn eine Webseite Statusnachrichten oder Benachrichtigungen einblendet, sollten diese auch von Screenreader-Usern automatisch vorgelesen werden – ohne den Fokus zu verschieben. Dafür kannst du ARIA-Live-Regions verwenden.

Wesentliche Inhalte müssen in Deutscher Gebärdensprache (DGS) bereitgestellt werden.

Auf der Startseite einer Website einer öffentlichen Stelle müssen nach §4 BITV 2.0 und Anlage 2 folgende Informationen als Video in Deutscher Gebärdensprache angeboten werden: (1) Informationen zu den wesentlichen Inhalten, (2) Hinweise zur Navigation, (3) eine Erläuterung der wesentlichen Inhalte der Erklärung zur Barrierefreiheit, (4) Hinweise auf weitere DGS-Inhalte im Auftritt. Die Videos müssen technische Anforderungen erfüllen: mindestens 320x240 Pixel, mindestens 25 Bilder/Sekunde, kontrastreicher Hintergrund, gut sichtbare Mimik und Mundbild, DGS-Logo zur Kennzeichnung.

Wesentliche Inhalte müssen in Leichter Sprache bereitgestellt werden.

Auf der Startseite einer Website einer öffentlichen Stelle müssen nach §4 BITV 2.0 und Anlage 2 folgende Informationen in Leichter Sprache angeboten werden: (1) Informationen zu den wesentlichen Inhalten, (2) Hinweise zur Navigation, (3) eine Erläuterung der wesentlichen Inhalte der Erklärung zur Barrierefreiheit, (4) Hinweise auf weitere Leichte-Sprache-Inhalte. Die Texte müssen den Regeln der Leichten Sprache folgen: kurze Sätze, einfache Begriffe, keine Abkürzungen, keine Verneinungen, keine Passiv-Konstruktionen, Schriftgröße mindestens 1.2em (120%), linksbündiger Text, heller Hintergrund, aussagekräftige Bilder.

Jede öffentliche Stelle muss eine vollständige Erklärung zur Barrierefreiheit bereitstellen.

Nach §7 BITV 2.0 und §12b BGG muss eine Erklärung zur Barrierefreiheit veröffentlicht werden. Sie muss: (1) barrierefrei und maschinenlesbar sein, (2) von der Startseite und jeder Seite erreichbar sein, (3) den Stand der Barrierefreiheit dokumentieren, (4) nicht barrierefreie Inhalte mit Begründung auflisten, (5) einen Feedback-Mechanismus enthalten, (6) auf das Schlichtungsverfahren hinweisen. Die Erklärung muss auf einer tatsächlichen Bewertung basieren und jährlich aktualisiert werden.

Ein barrierefreier Feedback-Mechanismus muss von jeder Seite erreichbar sein.

Nach §7 Abs. 2 BITV 2.0 und §12b Abs. 2 Nr. 2 BGG muss ein Feedback-Mechanismus bereitgestellt werden, über den Nutzer: (1) Barrieren melden können, (2) Informationen in barrierefreier Form anfordern können, (3) Auskunft über ausgenommene Inhalte erhalten können. Der Mechanismus muss von jeder Seite einer Website unmittelbar zugänglich und einfach zu benutzen sein. Er muss selbst barrierefrei sein.

Nutzer müssen über die Möglichkeit eines Schlichtungsverfahrens informiert werden.

Nach §7 BITV 2.0 und §12b Abs. 2 Nr. 3 BGG muss in der Erklärung zur Barrierefreiheit auf die Möglichkeit eines Schlichtungsverfahrens bei der Schlichtungsstelle nach §16 BGG hingewiesen werden. Nutzer können sich an die Schlichtungsstelle wenden, wenn ihre Anfrage über den Feedback-Mechanismus nicht innerhalb von sechs Wochen zufriedenstellend beantwortet wurde. Der Hinweis muss Kontaktdaten der Schlichtungsstelle enthalten.

Barrierefreiheitsfunktionen müssen ohne Barriere aktivierbar sein.

Wenn die Weblösung dokumentierte Barrierefreiheitsfunktionen hat, müssen diese aktivierbar sein, ohne auf eine Methode angewiesen zu sein, die diese Funktion selbst nicht unterstützt. Beispiel: Ein Screenreader-Modus darf nicht nur per Mausklick aktivierbar sein, sondern muss auch per Tastatur erreichbar sein.

Biometrische Verfahren dürfen nicht die einzige Authentifizierungsmethode sein.

Wenn biometrische Verfahren wie Fingerabdruck, Gesichtserkennung oder Iris-Scan zur Authentifizierung genutzt werden, muss mindestens eine alternative Methode zur Verfügung stehen, die nicht auf biologischen Merkmalen basiert. Dies ist wichtig für Menschen mit Behinderungen, die bestimmte biometrische Merkmale nicht nutzen können (z.B. fehlende Finger, Gesichtsveränderungen).

Barrierefreiheitsinformationen müssen bei Dokumentenkonvertierung erhalten bleiben.

Wenn Dokumente konvertiert, transformiert oder exportiert werden (z.B. Word zu PDF, HTML zu EPUB), müssen alle Barrierefreiheitsinformationen erhalten bleiben: Alt-Texte für Bilder, Überschriftenstruktur, Lesereihenfolge, Tabellenstruktur, Formularfelder-Beschriftungen und Sprachauszeichnungen.

Sprachkommunikation muss mindestens 7 kHz Audiobandbreite bieten.

Bei Zwei-Wege-Sprachkommunikation (z.B. VoIP, Videokonferenzen) muss die Audiobandbreite mindestens 7 kHz betragen (Breitband-Audio). Dies ermöglicht eine bessere Sprachverständlichkeit, insbesondere für Menschen mit Hörbeeinträchtigungen, die auf klare Audioqualität angewiesen sind.

Echtzeit-Textkommunikation (Real-Time Text) muss unterstützt werden.

Wenn die Weblösung Zwei-Wege-Sprachkommunikation bietet, muss auch Echtzeit-Textkommunikation (RTT) unterstützt werden. RTT überträgt Text zeichenweise in Echtzeit, nicht erst nach dem Absenden. Dies ist besonders wichtig für gehörlose und schwerhörige Menschen sowie für Situationen, in denen Sprache nicht möglich ist.

Sprache und Echtzeit-Text müssen gleichzeitig nutzbar sein.

Wenn die Weblösung sowohl Zwei-Wege-Sprachkommunikation als auch RTT bietet, müssen beide Kommunikationskanäle gleichzeitig nutzbar sein (Concurrent Voice and Text). Nutzer sollen nicht zwischen Sprache und Text wählen müssen, sondern beides parallel verwenden können.

Eingehende und ausgehende RTT-Nachrichten müssen visuell unterscheidbar sein.

Bei Echtzeit-Textkommunikation müssen eingehende und ausgehende Nachrichten visuell klar unterscheidbar sein. Dies kann durch unterschiedliche Farben, Positionen (links/rechts), Icons oder andere visuelle Merkmale erreicht werden.

Die Richtung von RTT-Nachrichten muss programmatisch ermittelbar sein.

Die Unterscheidung zwischen eingehenden und ausgehenden Echtzeit-Textnachrichten muss nicht nur visuell, sondern auch programmatisch ermittelbar sein. Screenreader und andere assistive Technologien müssen erkennen können, ob eine Nachricht gesendet oder empfangen wurde.

Bei Echtzeit-Textkommunikation muss der Absender identifizierbar sein.

In Gruppenchats oder Konferenzen mit Echtzeit-Textkommunikation muss klar erkennbar sein, wer welche Nachricht geschrieben hat. Der Absendername muss sowohl visuell als auch für assistive Technologien zugänglich sein.

Eine visuelle Anzeige muss zeigen, wenn jemand gerade spricht.

Bei Zwei-Wege-Sprachkommunikation muss eine visuelle Echtzeitanzeige vorhanden sein, die anzeigt, wenn Audio gesendet oder empfangen wird. Dies hilft gehörlosen und schwerhörigen Menschen zu erkennen, dass gerade gesprochen wird.

RTT muss mit anderen RTT-Systemen kompatibel sein.

Echtzeit-Textkommunikation muss mit anderen RTT-Systemen interoperabel sein, die gängige Standards wie RFC 4103 (RTP Payload for Text Conversation) unterstützen. Dies ermöglicht die Kommunikation zwischen verschiedenen Plattformen und Diensten.

RTT-Nachrichten müssen innerhalb von 500ms übertragen werden.

Die Verzögerung bei der Übertragung von Echtzeit-Text darf maximal 500 Millisekunden betragen. Eine längere Verzögerung würde den Charakter der Echtzeit-Kommunikation beeinträchtigen und die Konversation erschweren.

Bei Videokonferenzen mit Gebärdensprache muss der aktive Sprecher hervorgehoben werden.

Wenn die Weblösung Videokonferenzen unterstützt und Gebärdensprache verwendet wird, muss der aktive Sprecher visuell hervorgehoben werden. Dies kann durch einen Rahmen, Spotlight oder eine vergrößerte Darstellung des aktiven Teilnehmers erfolgen.

Der Videoplayer muss Untertitel korrekt wiedergeben können.

Wenn die Weblösung Videos mit Untertiteln anzeigt, muss der integrierte Videoplayer in der Lage sein, diese Untertitel korrekt wiederzugeben. Dies umfasst sowohl eingebettete Untertitel (Closed Captions) als auch externe Untertiteldateien (WebVTT, SRT).

Untertitel müssen synchron zum Audio sein (max. 100ms Verzögerung).

Die Wiedergabe von Untertiteln muss synchron zum entsprechenden Audio erfolgen. Die maximale Verzögerung zwischen Audio und Untertitel darf 100 Millisekunden nicht überschreiten, um eine gute Lesbarkeit und Verständlichkeit zu gewährleisten.

Untertitel müssen bei Übertragung, Konvertierung oder Aufzeichnung erhalten bleiben.

Wenn die Weblösung Videos überträgt, konvertiert oder aufzeichnet, müssen vorhandene Untertitel erhalten bleiben. Die Untertitelinformationen dürfen bei der Verarbeitung nicht verloren gehen.

Nutzer müssen Untertitel anpassen können (Größe, Farbe, Hintergrund).

Nutzer müssen die Möglichkeit haben, die Darstellung von Untertiteln anzupassen. Dazu gehören mindestens: Schriftgröße, Schriftfarbe, Hintergrundfarbe und Position. Dies ermöglicht eine individuelle Anpassung an verschiedene Sehbedürfnisse.

Untertitel sollten optional als Sprache ausgegeben werden können (Text-to-Speech).

Wenn die Weblösung Untertitel anzeigt, sollte sie optional die Möglichkeit bieten, diese auch als Sprache auszugeben (Text-to-Speech). Dies ist hilfreich für Menschen, die weder hören noch lesen können, oder in Situationen, wo das Lesen nicht möglich ist.

Der Videoplayer muss Audiodeskription korrekt wiedergeben können.

Wenn die Weblösung Videos mit Audiodeskription anzeigt, muss der integrierte Videoplayer in der Lage sein, diese Audiodeskription korrekt wiederzugeben. Die zusätzliche Audiospur mit Beschreibungen visueller Inhalte muss abspielbar sein.

Audiodeskription muss synchron zum Video sein.

Die Wiedergabe von Audiodeskription muss synchron zum entsprechenden Video erfolgen. Die Beschreibungen müssen in den Dialogpausen platziert sein und zeitlich zum visuellen Geschehen passen.

Audiodeskription muss bei Übertragung, Konvertierung oder Aufzeichnung erhalten bleiben.

Wenn die Weblösung Videos überträgt, konvertiert oder aufzeichnet, muss vorhandene Audiodeskription erhalten bleiben. Die zusätzliche Audiospur darf bei der Verarbeitung nicht verloren gehen.

Ein/Aus-Schalter für Untertitel und Audiodeskription müssen vorhanden und zugänglich sein.

Wenn die Weblösung Videos mit Untertiteln oder Audiodeskription anzeigt, müssen Bedienelemente zum Ein- und Ausschalten dieser Funktionen vorhanden sein. Diese Bedienelemente müssen selbst barrierefrei sein (per Tastatur bedienbar, mit Screenreader nutzbar).

System- und Browser-Einstellungen zur Barrierefreiheit müssen respektiert werden.

Die Weblösung muss die Barrierefreiheitseinstellungen des Betriebssystems oder Browsers respektieren. Dazu gehören: Schriftgröße, Farbschema (z.B. Dunkelmodus), reduzierte Bewegung (prefers-reduced-motion), hoher Kontrast und Animationseinstellungen.

Autorenwerkzeuge müssen die Erstellung barrierefreier Inhalte ermöglichen und fördern.

Wenn die Weblösung ein Autorenwerkzeug ist (z.B. CMS, WYSIWYG-Editor, Website-Builder), muss sie die Erstellung barrierefreier Inhalte unterstützen und aktiv fördern. Dazu gehören: Alt-Text-Eingabe für Bilder, Überschriften-Strukturierung, Tabellenauszeichnung und Formular-Beschriftungen.

Bei Umstrukturierung von Inhalten müssen Barrierefreiheitsinformationen erhalten bleiben.

Wenn die Weblösung Inhalte transformiert oder umstrukturiert (z.B. beim Kopieren, Einfügen, Formatwechsel), müssen alle Barrierefreiheitsinformationen erhalten bleiben, soweit das Zielformat dies unterstützt.

Autorenwerkzeuge sollten Funktionen zur Prüfung und Reparatur von Barrierefreiheitsproblemen bieten.

Wenn die Weblösung ein Autorenwerkzeug ist, sollte sie Funktionen zur Überprüfung und Reparatur von Barrierefreiheitsproblemen bieten. Dazu gehören: Warnungen bei fehlenden Alt-Texten, Hinweise auf Kontrastprobleme und Vorschläge zur Strukturverbesserung.

Vorlagen in Autorenwerkzeugen müssen selbst barrierefrei sein.

Wenn die Weblösung Vorlagen für die Inhaltserstellung bereitstellt (z.B. Seitenvorlagen, E-Mail-Templates, Dokumentvorlagen), müssen diese Vorlagen selbst barrierefrei sein und barrierefreie Inhalte ermöglichen. Vorlagen sollten korrekte Überschriftenstruktur, ausreichende Kontraste und semantisches Markup enthalten.

Die Produktdokumentation muss Barrierefreiheitsfunktionen und AT-Kompatibilität beschreiben.

Die Produktdokumentation muss alle Barrierefreiheitsfunktionen beschreiben und deren Kompatibilität mit assistiven Technologien dokumentieren. Nutzer müssen erfahren können, welche A11y-Features verfügbar sind und wie sie mit Screenreadern, Vergrößerungssoftware etc. funktionieren.

Die Produktdokumentation selbst muss barrierefrei sein.

Alle Produktdokumentation muss in mindestens einem barrierefreien Format bereitgestellt werden, das den WCAG-Anforderungen entspricht. PDFs müssen getaggt sein, HTML-Dokumentation muss semantisch korrekt sein, Videos in der Dokumentation brauchen Untertitel.

Der technische Support muss Informationen zu Barrierefreiheitsfunktionen bereitstellen können.

Der technische Support muss Informationen zu den Barrierefreiheitsfunktionen des Produkts bereitstellen können und Nutzer bei deren Verwendung unterstützen. Support-Mitarbeiter sollten geschult sein, um Fragen zur Nutzung mit assistiven Technologien beantworten zu können.

Der Support muss über verschiedene barrierefreie Kommunikationskanäle erreichbar sein.

Der Support muss über verschiedene barrierefreie Kommunikationskanäle erreichbar sein. Dazu gehören: Telefon (mit Relay-Dienst-Unterstützung), E-Mail, Chat (barrierefrei), Kontaktformular (barrierefrei). Nicht nur ein Kanal darf angeboten werden.

Support-Dokumentation und Anleitungen müssen barrierefrei sein.

Alle vom Support bereitgestellten Dokumente und Anleitungen müssen in barrierefreien Formaten verfügbar sein. Dies gilt für FAQ-Dokumente, Troubleshooting-Guides, Anleitungen per E-Mail und alle anderen Support-Materialien.