WCAG 2.2: wie jede Anforderung geprüft wird

Anforderungen: 55 · Prüfschritte: 50

Bevor Sie beginnen

Diese Prüfschritte beschreiben, was zu prüfen ist und wie Sie entscheiden. Einige Gewohnheiten machen die Ergebnisse verlässlich, unabhängig davon, welchen Browser und welche assistiven Technologien Sie verwenden.

  • Testen Sie mit mindestens zwei Kombinationen aus Browser und Screenreader, die Ihre Nutzenden verwenden. Übliche Kombinationen sind NVDA mit Firefox oder Chrome und JAWS mit Chrome unter Windows, VoiceOver mit Safari unter macOS und iOS sowie TalkBack mit Chrome unter Android. Screenreader und Browser unterscheiden sich darin, was sie ansagen, daher gilt ein Ergebnis mit einer Kombination nicht für alle. Weichen sie voneinander ab, halten Sie fest, mit welcher Kombination die Prüfung nicht bestanden wurde.
  • Führen Sie Tastaturtests mit ausgeschaltetem Screenreader durch. Im Lesemodus kann ein Screenreader Elemente aktivieren, die mit der Tastatur allein nicht erreichbar sind, und so Tastaturfehler verdecken.
  • Aktivieren Sie auf einem Mac in den Systemeinstellungen unter „Tastatur“ die „Tastaturnavigation“, und aktivieren Sie in Safari in den Einstellungen unter „Erweitert“ die Option, mit der die Tabulatortaste jedes Objekt auf einer Webseite hervorhebt. Ohne diese Einstellungen überspringt Tab Links und einige Bedienelemente, und Sie halten Fehler fest, die es nicht gibt.
  • Um einen Tastaturdurchgang am Anfang der Seite zu beginnen, laden Sie sie neu und drücken Sie Tab, ohne zu klicken, oder klicken Sie in einen leeren Bereich direkt über dem ersten Link oder Bedienelement. Ein Start in der Adressleiste ist unzuverlässig: Manche Browser bewegen den Fokus zuerst durch ihre eigene Symbolleiste oder die Vorschläge der Adressleiste.
  • Jeder Browser zeigt den Barrierefreiheitsbaum an einer anderen Stelle: Chrome und Edge im Bereich „Barrierefreiheit“ unter „Elemente“ (aktivieren Sie den Barrierefreiheitsbaum für die ganze Seite, um die gesamte Seite zu sehen), Firefox im Barrierefreiheitsinspektor und Safari im Abschnitt zur Barrierefreiheit im Bereich „Knoten“ im Tab „Elemente“. Wo ein Prüfschritt den Bereich „Barrierefreiheit“ der Entwicklertools nennt, verwenden Sie den des Browsers, den Sie testen.
  • Die Gerätesymbolleiste der Entwicklertools ändert die Größe des Viewports, bildet aber Zoom, Drehung, Gesten und Screenreader eines echten Smartphones nicht nach. Bestätigen Sie Ergebnisse für Mobilgeräte auf einem echten Gerät.
  • Testen Sie jeden Zustand, den die Seite haben kann, nicht nur den nach dem ersten Laden: geöffnete Menüs und Dialoge, Fehlermeldungen, leere und volle Listen, Ansichten mit und ohne Anmeldung.
  • Mit „nur Indiz“ markierte Regeln können nicht allein entscheiden. Behandeln Sie, was sie melden, als Liste von Stellen, die Sie von Hand prüfen.

1 Wahrnehmbar

1.1 Textalternativen

1.1.1 Nicht-Text-Inhalt

Stufe A

Nicht-Text-Inhalte, die etwas vermitteln, haben eine Textalternative
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie auf der ganzen Seite nach Inhalten, die kein Text sind: Fotos, Symbole, Logos, Diagramme, Karten, Schaubilder, Posterbilder von Videos und die Bilder in Schaltflächen und Links.
  2. Wählen Sie jeden davon im Bereich „Elemente“ der Entwicklertools aus und lesen Sie im Bereich „Barrierefreiheit“ den Eintrag „Name“.
  3. Notieren Sie jeden, der keinen Namen hat und nicht vor assistiven Technologien verborgen ist (mit alt="", aria-hidden="true", role="presentation" oder als CSS-Hintergrund).
  4. Suchen Sie auch nach Informationen, die nur CSS anzeigt: Hintergrundbilder, Icon-Fonts und Bilder, die mit der Eigenschaft content eingefügt sind. Untersuchen Sie jedes davon, da es kein alt-Attribut zum Lesen gibt, und prüfen Sie, ob das Gezeigte auch als Text vorliegt, den ein Screenreader vorliest.
  5. Prüfen Sie bei Inhalten, die sich nicht in wenigen Worten beschreiben lassen, etwa einem Diagramm oder einer Karte, ob der Name zumindest sagt, was es ist, und ob eine ausführlichere Beschreibung auf der Seite steht oder daneben verlinkt ist.
Bestanden, wenn
Jeder Nicht-Text-Inhalt, den eine Person braucht, hat eine Textalternative oder ist vor assistiven Technologien verborgen, weil er dekorativ ist.
Nicht bestanden, wenn
Nicht-Text-Inhalt, der etwas vermittelt, hat keine Textalternative, sodass Screenreader-Nutzende auf ein unbenanntes Bild oder auf gar nichts stoßen; das verstößt gegen WCAG 1.1.1.

Regeln, die es prüfen: img-alt-present, role-img-text-alternative-present, canvas-text-alternative-present, embed-text-alternative-present, svg-text-alternative-present, svg-image-text-alternative-present, object-text-alternative-present, video-poster-text-alternative-present, meter-name-present, progressbar-name-present

Dieser Prüfschritt prüft auch:

  • <img> hat ein alt-Attribut
  • role="img" hat eine Textalternative
  • <canvas> hat Fallback-Text oder einen zugänglichen Namen
  • <embed> hat Fallback-Text oder einen zugänglichen Namen
  • <svg> hat einen Mechanismus für eine Textalternative, wenn es bereitgestellt wird
  • Inline-<svg> hat ein <title> oder einen zugänglichen Namen
  • SVG-<image> hat einen Mechanismus für eine Textalternative
  • <object> hat Fallback-Text oder einen zugänglichen Namen
  • <video poster> hat einen Mechanismus für eine Textalternative
  • Elemente mit role="meter" stellen einen zugänglichen Namen bereit
  • Elemente mit role="progressbar" stellen einen zugänglichen Namen bereit
Bilder und Symbole, die als Bedienelemente dienen, sind nach ihrer Funktion benannt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie jeden Link, jede Schaltfläche und jedes andere Bedienelement, deren einziger Inhalt ein Bild oder Symbol ist, etwa ein Logo, das zur Startseite führt, eine Lupe für die Suche oder ein Kreuz, das einen Dialog schließt.
  2. Wählen Sie jedes davon im Bereich „Elemente“ der Entwicklertools aus und lesen Sie im Bereich „Barrierefreiheit“ den Eintrag „Name“.
  3. Prüfen Sie, ob der Name sagt, was das Bedienelement tut oder wohin es führt („Suche“, „Schließen“, „Startseite“), und nicht beschreibt, was das Bild zeigt („Lupe“), oder ein Dateiname ist.
Bestanden, wenn
Jedes Bedienelement, das aus einem Bild oder Symbol besteht, hat einen Namen, der sagt, was es tut oder wohin es führt.
Nicht bestanden, wenn
Ein Bedienelement, das aus einem Bild oder Symbol besteht, hat keinen Namen oder einen, der das Bild beschreibt statt seiner Funktion; das verstößt gegen WCAG 1.1.1.

Regeln, die es prüfen: input-image-alt-present, area-alt-present

Dieser Prüfschritt prüft auch:

  • <input type="image"> hat ein alt-Attribut
  • <area> hat ein alt-Attribut
Dekorative Bilder sind vor assistiven Technologien verborgen, und nur diese
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie auf der Seite nach Bildern, Symbolen und Grafiken, die nur schmücken: Rahmen, Trennlinien, Hintergrundbilder, Ornamente und Bilder, deren Inhalt der Text daneben bereits wiedergibt.
  2. Wählen Sie jedes davon im Bereich „Elemente“ der Entwicklertools aus und prüfen Sie im Bereich „Barrierefreiheit“, ob es ignoriert wird (alt="", aria-hidden="true", role="presentation" oder ein CSS-Hintergrund).
  3. Prüfen Sie bei einem dekorativen SVG, das in der Seite gezeichnet wird, ob es aria-hidden="true" hat. Ohne dieses Attribut sagen manche Kombinationen aus Browser und Screenreader es als Bild ohne Namen an oder lesen den Text darin vor.
  4. Prüfen Sie dann umgekehrt bei jedem so verborgenen Bild, ob Nutzenden etwas fehlen würde, wenn es nicht da wäre: Informationen, eine Beschriftung, die Daten eines Diagramms.
Bestanden, wenn
Dekorative Bilder sind vor assistiven Technologien verborgen, und jedes verborgene Bild ist tatsächlich dekorativ.
Nicht bestanden, wenn
Ein dekoratives Bild wird angesagt (oft mit seinem Dateinamen), oder ein Bild, das Informationen vermittelt, ist vor assistiven Technologien verborgen; das verstößt gegen WCAG 1.1.1.
Jede Textalternative gibt wieder, was ihr Bild vermittelt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Lesen Sie bei jedem Bild und jedem anderen Nicht-Text-Inhalt mit Textalternative die Alternative (den Namen im Bereich „Barrierefreiheit“ der Entwicklertools) und betrachten Sie den Inhalt an seiner Stelle auf der Seite.
  2. Fragen Sie sich, was der Inhalt Lesenden an dieser Stelle vermittelt, und prüfen Sie, ob die Alternative dasselbe vermittelt: die Wörter in einem Bild von Text, die Aussage eines Fotos, die Fakten, die ein Diagramm zeigt.
  3. Nennt die Alternative ein komplexes Bild wie ein Diagramm oder Schaubild nur, prüfen Sie, ob die Details in einer Bildunterschrift, einem Text oder einer Tabelle daneben oder hinter einem Link daneben stehen, die Screenreader-Nutzende vom Bild aus finden können.
  4. Notieren Sie Alternativen, die ein Dateiname, eine Webadresse oder ein Wort wie „Bild“ oder „Foto“ sind oder den Text direkt daneben wiederholen.
  5. Prüfen Sie die Sprache jeder Alternative: Sie sollte in der Sprache der Seite sein oder mit ihrer eigenen Sprache ausgezeichnet sein.
Bestanden, wenn
Jede Textalternative vermittelt, was ihr Inhalt an dieser Stelle vermittelt, direkt oder über eine Beschreibung, die Screenreader-Nutzende von ihr aus erreichen können.
Nicht bestanden, wenn
Eine Textalternative vermittelt nicht, was der Inhalt vermittelt, zum Beispiel ein Dateiname, ein allgemeines Wort oder ein benanntes Diagramm, dessen Daten nirgends stehen; das verstößt gegen WCAG 1.1.1 (F30).

Regeln, die es prüfen: area-alt-quality, canvas-text-alternative-quality, embed-text-alternative-quality, img-alt-decorative, img-alt-quality, input-image-alt-decorative, input-image-alt-quality, object-text-alternative-quality, svg-text-alternative-quality

Dieser Prüfschritt prüft auch:

  • Die Textalternative ist angemessen und gleichwertig
  • Verdächtige Muster im Alternativtext (z. B. Dateiname/Platzhalter)
Ein CAPTCHA sagt, wofür es dient, und bietet eine andere Form an, die einen anderen Sinn nutzt
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Ein Screenreader
  1. Suchen Sie jeden Test, mit dem die Seite Menschen von Programmen unterscheidet, etwa verzerrte Buchstaben zum Abtippen, Bilder zum Auswählen oder ein Puzzle zum Ziehen.
  2. Prüfen Sie, ob er eine Textalternative hat, die sagt, was er ist und was zu tun ist, ohne die Lösung zu verraten.
  3. Prüfen Sie, ob er eine andere Form anbietet, die einen anderen Sinn nutzt, etwa eine Audioversion eines visuellen Tests, oder einen ganz anderen Weg, etwa einen Code per E-Mail.
  4. Probieren Sie die andere Form mit einem Screenreader und der Tastatur aus.
Bestanden, wenn
Die Seite hat keinen solchen Test, oder der Test sagt, was er ist, und bietet eine Form an, die einen anderen Sinn nutzt und sich abschließen lässt.
Nicht bestanden, wenn
Der Test lässt sich nur durch Sehen (oder nur durch Hören) bestehen oder hat keinen Text, der sagt, was er ist; das verstößt gegen WCAG 1.1.1.

1.2 Zeitbasierte Medien

1.2.1 Reine Audio- und Videoinhalte (aufgezeichnet)

Stufe A

Aufgezeichnete reine Audio- und Videoinhalte haben ein Transkript oder eine gleichwertige Alternative
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: nur ein Browser
  1. Suchen Sie jeden Audioplayer und jedes Video ohne Ton auf der Seite, auch in Frames, und spielen Sie jedes ab.
  2. Suchen Sie bei Audio neben dem Player und anderswo auf der Seite nach einem Transkript oder einem Link darauf.
  3. Suchen Sie bei einem Video ohne Ton nach einem Transkript oder einer Audioversion, die alles Gezeigte beschreibt und die Sie von der Seite aus mit der Tastatur finden und abspielen können.
  4. Vergleichen Sie jede Alternative mit dem Medium und prüfen Sie, ob sie dieselben Informationen wiedergibt: Sprache, wichtige Geräusche und das Gezeigte.
  5. Lassen Sie Medien weg, die selbst eine Alternative für Text auf der Seite und als solche gekennzeichnet sind.
Bestanden, wenn
Jeder aufgezeichnete reine Audio- oder Videoinhalt hat ein Transkript oder, bei Video, eine Audioversion, die wiedergibt, was er vermittelt, oder ist eine gekennzeichnete Alternative für Text auf der Seite.
Nicht bestanden, wenn
Aufgezeichnete reine Audioinhalte haben kein Transkript, oder aufgezeichnete reine Videoinhalte haben weder ein Transkript noch eine Audioversion mit denselben Informationen; das verstößt gegen WCAG 1.2.1.

Regeln, die es prüfen: media-alternative-transcript-evidence

1.2.2 Untertitel (aufgezeichnet)

Stufe A

Aufgezeichnete Videos mit Ton haben Untertitel
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: nur ein Browser
  1. Suchen Sie jedes aufgezeichnete Video mit Ton auf der Seite, auch in Frames und in Playern anderer Websites.
  2. Spielen Sie jedes mit eingeschaltetem Ton ab und notieren Sie, ob sein Ton Informationen trägt: Sprache oder wichtige Geräusche.
  3. Wenn ja, suchen Sie nach Untertiteln: die CC-Schaltfläche des Players, ins Bild eingebrannte Untertitel oder eine daneben verlinkte untertitelte Fassung desselben Videos. Ein Transkript allein ersetzt keine Untertitel.
  4. Lassen Sie ein Video weg, das selbst eine Alternative für Text auf der Seite und als solche gekennzeichnet ist.
Bestanden, wenn
Jedes aufgezeichnete Video, dessen Ton Informationen trägt, hat Untertitel, hier oder in einer daneben verlinkten untertitelten Fassung, oder ist eine gekennzeichnete Alternative für Text auf der Seite.
Nicht bestanden, wenn
Ein aufgezeichnetes Video hat Dialoge oder wichtige Geräusche und keine Untertitel, weder hier noch in einer verlinkten untertitelten Fassung, auch wenn ein Transkript angeboten wird; das verstößt gegen WCAG 1.2.2.

Regeln, die es prüfen: video-caption

Untertitel geben alle Dialoge, die sprechende Person und die wichtigen Geräusche wieder, synchron zum Video
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: nur ein Browser
  1. Spielen Sie jedes untertitelte Video mit eingeschaltetem Ton und eingeschalteten Untertiteln ab.
  2. Vergleichen Sie die Untertitel durchgehend mit dem, was gesagt wird und zu hören ist.
  3. Prüfen Sie, ob sie alle Dialoge enthalten, angeben, wer spricht, wenn das nicht klar ist, die wichtigen Geräusche beschreiben (Musik, Alarme, Lachen) und synchron zum Bild bleiben.
  4. Gehen Sie mit automatisch erzeugten Untertiteln vorsichtig um: Sie geben Namen, Zahlen und Satzzeichen oft falsch wieder und beschreiben keine Geräusche, daher erfüllen sie dieses Kriterium ohne Überarbeitung selten.
Bestanden, wenn
Die Untertitel enthalten alle Dialoge, wo nötig die sprechenden Personen und die wichtigen Geräusche, synchron zum Video.
Nicht bestanden, wenn
Untertitel lassen Dialoge oder wichtige Geräusche aus, geben nicht an, wer spricht, wo das wichtig ist, oder laufen nicht synchron zum Video; das verstößt gegen WCAG 1.2.2 (F8).

1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet)

Stufe A

Aufgezeichnete Videos mit Ton haben eine Audiodeskription oder eine vollständige Textalternative
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.2.4 Untertitel (Live)

Stufe AA

Live-Videos mit Ton haben Untertitel
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.2.5 Audiodeskription (aufgezeichnet)

Stufe AA

Aufgezeichnete Videos mit Ton haben eine Audiodeskription
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.3 Anpassbar

1.3.1 Info und Beziehungen

Stufe A

Text, der wie eine Überschrift aussieht, ist als Überschrift ausgezeichnet, mit einer Ebene, die zur Gliederung der Seite passt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Gehen Sie die Seite durch und notieren Sie jeden Text, der als Überschrift wirkt: Er ist größer oder fetter als der umgebende Text und leitet das Folgende ein.
  2. Prüfen Sie bei jedem im Bereich „Elemente“ der Entwicklertools, ob er ein <h1> bis <h6> ist oder role="heading" mit einem aria-level hat.
  3. Prüfen Sie umgekehrt, ob jedes Überschriftenelement auf der Seite Inhalte einleitet und nicht nur dazu dient, Text groß darzustellen.
  4. Listen Sie die Überschriften über die Überschriftenliste eines Screenreaders, eine Browsererweiterung wie HeadingsMap oder den Bereich „Barrierefreiheit“ auf und prüfen Sie, ob ihre Ebenen der Struktur entsprechen, die die Seite zeigt: Die Unterüberschriften eines Abschnitts liegen unter seiner Überschrift, nicht auf derselben Ebene oder darüber. Eine übersprungene Ebene allein, etwa ein h2 gefolgt von einem h4, verstößt nicht gegen dieses Kriterium, wenn die Verschachtelung trotzdem stimmt. Halten Sie sie als Best-Practice-Befund fest.
Bestanden, wenn
Jede visuelle Überschrift ist als Überschrift ausgezeichnet, jedes Überschriftenelement ist tatsächlich eine Überschrift, und die Ebenen folgen der Gliederung, die die Seite zeigt.
Nicht bestanden, wenn
Text, der wie eine Überschrift aussieht, ist einfacher Text, ein Überschriftenelement wird nur wegen seiner Größe verwendet, oder die Ebenen widersprechen der Gliederung, sodass Screenreader-Nutzende die Abschnitte nicht finden oder ihnen nicht folgen können; das verstößt gegen WCAG 1.3.1.

Regeln, die es prüfen: p-as-heading

Dieser Prüfschritt prüft auch:

  • Fetter <p>-Text in Überschriftengröße, der ein echtes Überschriftenelement brauchen könnte (nur Indiz)
Inhalte, die als Liste dargestellt werden, sind als Liste ausgezeichnet
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie auf der Seite nach Inhalten, die als Liste dargestellt werden: Einträge in einer Zeile oder Spalte mit Aufzählungszeichen, Nummern oder gleichem Layout, etwa Menüs, Schritte und Gruppen von Links.
  2. Prüfen Sie bei jedem im Bereich „Elemente“ der Entwicklertools, ob es ein <ul>, <ol> oder <dl> ist (oder role="list" mit Einträgen mit role="listitem" hat).
  3. Prüfen Sie, ob jede Liste direkt nur Listeneinträge enthält und jeder Listeneintrag in einer Liste liegt.
  4. Wenn Sie mit VoiceOver und Safari testen, beachten Sie, dass Safari eine Liste, deren Aufzählungszeichen mit list-style: none entfernt wurden, nur mit role="list" als Liste bereitstellt. Das ist eine Entscheidung des Browsers, kein Fehler der Seite, aber notieren Sie es, wenn die Struktur der Liste für Nutzende wichtig ist.
Bestanden, wenn
Inhalte, die als Liste dargestellt werden, sind als Liste ausgezeichnet, und das Listen-Markup ist vollständig.
Nicht bestanden, wenn
Inhalte, die als Liste dargestellt werden, sind eine Folge von Absätzen, Zeilenumbrüchen oder divs, oder das Listen-Markup ist fehlerhaft, sodass ein Screenreader nicht sagt, dass es eine Liste ist oder wie viele Einträge sie hat; das verstößt gegen WCAG 1.3.1.

Regeln, die es prüfen: list-children-valid, listitem-parent-valid, definition-list-children-valid, dlitem-parent-valid

Dieser Prüfschritt prüft auch:

  • <ul>/<ol> enthalten direkt nur <li> (oder <script>/<template>)
  • <li>-Elemente liegen in einem Listencontainer (<ul>/<ol>/role="list")
  • <dl> enthält direkt nur Gruppen aus <dt>/<dd> (optional in einem <div> zusammengefasst), <script>, <template> oder <style>
  • <dt>/<dd>-Elemente liegen in einem <dl>, direkt oder über ein umschließendes <div>
Datentabellen zeichnen ihre Kopfzellen und ihre Tabellenbeschriftung aus, und reine Layouttabellen haben kein Kopfzellen-Markup
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Suchen Sie jede Tabelle auf der Seite und jedes Datenraster, das ohne Tabelle dargestellt wird.
  2. Prüfen Sie bei einer Datentabelle im Bereich „Elemente“ der Entwicklertools, ob ihre Kopfzellen <th> sind (mit scope, wo eine Kopfzelle nicht eindeutig eine Zeilen- oder Spaltenüberschrift ist) und ob ein darüber angezeigter Titel ihre <caption> ist.
  3. Prüfen Sie bei einer komplexen Tabelle mit Kopfzellen auf mehr als einer Ebene, ob jede Datenzelle ihre Kopfzellen über ein headers-Attribut oder scope angibt.
  4. Gehen Sie mit einem Screenreader einige Datenzellen durch und prüfen Sie, ob er ihre Kopfzellen mit vorliest.
  5. Prüfen Sie bei einer Tabelle, die nur dem Layout dient, ob sie kein <th>, keine <caption> und kein summary hat.
Bestanden, wenn
Daten stehen in Tabellen, deren Kopfzellen und Tabellenbeschriftung ausgezeichnet sind, ein Screenreader liest zu jeder Zelle ihre Kopfzellen vor, und Layouttabellen haben kein Kopfzellen-Markup.
Nicht bestanden, wenn
Eine Datentabelle hat kein Kopfzellen-Markup oder eine nachgebildete Tabellenbeschriftung in einer Zelle, Daten sind als Raster ohne Tabelle angeordnet, oder eine Layouttabelle ist als Datentabelle ausgezeichnet; das verstößt gegen WCAG 1.3.1.

Regeln, die es prüfen: table-headers-attr-valid, table-th-has-data-cells, table-fake-caption, td-has-header

Dieser Prüfschritt prüft auch:

  • Das headers-Attribut von Tabellenzellen verweist auf gültige <th>-Zellen in derselben Tabelle
  • Tabellen mit <th>-Zellen haben auch Datenzellen, die diese beschreiben
  • Zelle in der ersten Tabellenzeile, die eine echte <caption> ersetzen könnte (nur Indiz)
  • Datenzellen in großen, einfachen Tabellen haben eine zugeordnete Kopfzelle
Formularfelder sind mit ihren sichtbaren Beschriftungen verknüpft, Gruppen von Feldern mit dem Text, der die Gruppe benennt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Suchen Sie jedes Formularfeld auf der Seite: Textfelder, Kontrollkästchen, Optionsfelder, Auswahllisten und benutzerdefinierte Bedienelemente.
  2. Wählen Sie jedes davon im Bereich „Elemente“ der Entwicklertools aus und prüfen Sie, ob der Eintrag „Name“ im Bereich „Barrierefreiheit“ seine sichtbare Beschriftung enthält.
  3. Prüfen Sie bei einer Gruppe von Feldern unter einer Frage, etwa Optionsfeldern oder einem Datum in drei Teilen, ob die Gruppe ein <fieldset> mit einer <legend> ist oder role="group" mit einem Namen hat, sodass die Frage mit jedem Feld vorgelesen wird.
  4. Prüfen Sie, ob neben einem Feld angezeigte Anweisungen (ein Format, eine Pflichtfeldmarkierung) über aria-describedby mit ihm verknüpft sind oder in seiner Beschriftung stehen.
Bestanden, wenn
Der Name jedes Feldes enthält seine sichtbare Beschriftung, Gruppen von Feldern sind nach ihrer Frage benannt, und die Anweisungen zu einem Feld sind mit ihm verknüpft.
Nicht bestanden, wenn
Ein Feld ist nur durch Text in der Nähe beschriftet, der nicht mit ihm verknüpft ist, oder die Frage einer Gruppe ist nicht mit ihren Feldern verknüpft, sodass ein Screenreader ein Feld vorliest, ohne zu sagen, wofür es dient; das verstößt gegen WCAG 1.3.1.

Regeln, die es prüfen: form-control-programmatic-label-present

Dieser Prüfschritt prüft auch:

  • Formularelemente haben eine programmatisch ermittelbare Beschriftung (label/aria-label/aria-labelledby/title/placeholder)
  • Beschriftungen von Formularelementen sind angemessen
ARIA-Rollen und -Beziehungen ergeben dieselbe Struktur, die die Seite zeigt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie die Teile der Seite, die mit ARIA-Rollen gebaut sind: benutzerdefinierte Menüs, Tabs, Bäume, Grids, Listen und Listenfelder.
  2. Öffnen Sie bei jedem den Barrierefreiheitsbaum der Entwicklertools und prüfen Sie, ob die dort gezeigte Struktur dem entspricht, was auf dem Bildschirm zu sehen ist: eine tablist mit Tabs, ein Menü mit Menüeinträgen, ein Grid mit Zeilen und Zellen.
  3. Prüfen Sie, ob keinem Element mit einer Rolle das Elternelement oder die Kinder fehlen, die seine Rolle braucht, und ob aria-owns, wo es verwendet wird, jedem Element genau einen Besitzer gibt.
  4. Prüfen Sie, ob <body> nicht mit aria-hidden="true" verborgen ist.
Bestanden, wenn
Der Barrierefreiheitsbaum gibt die Struktur wieder, die die Seite zeigt, und jede Rolle steht an der Stelle, die sie braucht.
Nicht bestanden, wenn
Einer Rolle fehlt das erforderliche Elternelement oder fehlen die erforderlichen Kinder, ein Element ist zweimal zugeordnet, oder die Seite ist im Baum verborgen, sodass assistive Technologien eine Struktur wiedergeben, die nicht zum Bildschirm passt; das verstößt gegen WCAG 1.3.1.

Regeln, die es prüfen: aria-hidden-body, aria-required-children, aria-prohibited-children, aria-required-parent, aria-roles-valid, aria-owns-valid

Dieser Prüfschritt prüft auch:

  • Das <body> des Dokuments hat kein aria-hidden="true"
  • Container-Rollen (list, listbox, menu, table, tablist, tree, ...) haben mindestens ein zugeordnetes Kind mit einer erforderlichen Rolle
  • Container-Rollen haben kein zugeordnetes Kind im Barrierefreiheitsbaum mit einer nicht erlaubten Rolle
  • Rollen, die eine bestimmte Kontextrolle erfordern (listitem, option, tab, treeitem, row, cell, ...), haben einen passenden Vorfahren oder Besitzer
  • Ein explizites role-Attribut ergibt eine echte, nicht abstrakte ARIA-Rolle, sodass die vermittelte Struktur programmatisch ermittelbar ist
  • aria-owns gibt jedem Element genau einen Besitzer und nie einen Vorfahren des Besitzers
Bedeutung, die durch Gestaltung oder Layout vermittelt wird, etwa Fettdruck, Farbe, Position oder ein Sternchen, steht auch im Markup oder im Text
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Suchen Sie nach Bedeutung, die die Seite nur durch das Aussehen zeigt: Pflichtfelder, die mit einem Sternchen oder einer Farbe markiert sind, hervorgehobene oder durchgestrichene Wörter, ein ausgewählter Eintrag, der nur durch seinen Stil erkennbar ist, Text, der in einem Kasten abgesetzt ist.
  2. Prüfen Sie bei jedem, ob dieselbe Bedeutung im Markup (etwa required, aria-current, <em>, <del>) oder im Text selbst steht („Pflichtfeld“, „aktuelle Seite“).
  3. Sehen Sie sich Text und Symbole an, die mit CSS über die Eigenschaft content eingefügt werden. Browser unterscheiden sich darin, ob Screenreader sie vorlesen, daher müssen Informationen, die nur CSS hinzufügt, auch im Markup oder im Text stehen.
  4. Lesen Sie die Stellen mit einem Screenreader und prüfen Sie, ob das, was die Gestaltung zeigt, angesagt wird.
Bestanden, wenn
Was Gestaltung oder Layout vermitteln, steht auch im Markup oder im Text.
Nicht bestanden, wenn
Bedeutung wird nur durch Gestaltung oder Position vermittelt, etwa Pflichtfelder, die nur durch Farbe oder ein unerklärtes Sternchen markiert sind, sodass Screenreader-Nutzende sie nicht mitbekommen; das verstößt gegen WCAG 1.3.1.

1.3.2 Bedeutungstragende Reihenfolge

Stufe A

Die Reihenfolge, in der assistive Technologien die Inhalte vorlesen, erhält ihre Bedeutung, und Text wird nicht mit Leerzeichen gestaltet
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.3.3 Sensorische Eigenschaften

Stufe A

Anweisungen beruhen nicht nur auf Form, Farbe, Größe, Position, Ausrichtung oder Ton
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.3.4 Bildschirmausrichtung

Stufe AA

Die Seite funktioniert im Hoch- und im Querformat, sofern nicht eine Ausrichtung wesentlich ist
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Öffnen Sie die Seite in der Gerätesymbolleiste der Entwicklertools oder auf einem Smartphone oder Tablet.
  2. Betrachten Sie sie im Hochformat, drehen Sie sie dann ins Querformat (oder umgekehrt) und nutzen Sie in beiden ihre Hauptinhalte und Bedienelemente.
  3. Bestätigen Sie das Ergebnis auf einem echten Smartphone oder Tablet mit ausgeschalteter Rotationssperre. Die Gerätesymbolleiste kann nicht zeigen, ob die Seite die Ausrichtung per Skript oder, bei einer installierten Web-App, über ihr Manifest festlegt.
  4. Prüfen Sie, ob die Seite Sie nicht auffordert, das Gerät zu drehen, ihre Inhalte nicht seitlich dreht und in keiner Ausrichtung Inhalte verbirgt.
  5. Wenn doch, fragen Sie sich, ob diese Ausrichtung wesentlich ist, wie bei einem Bankscheck oder einer Klaviertastatur.
Bestanden, wenn
Die Seite wird in beiden Ausrichtungen angezeigt und funktioniert in beiden, oder eine Ausrichtung ist für sie wesentlich.
Nicht bestanden, wenn
Die Seite funktioniert nur in einer Ausrichtung, indem sie auffordert, das Gerät zu drehen, ihre Inhalte dreht oder verbirgt, ohne dass dies wesentlich ist; das verstößt gegen WCAG 1.3.4.

Regeln, die es prüfen: css-orientation-lock

Dieser Prüfschritt prüft auch:

  • Keine CSS-Media-Query für die Ausrichtung dreht die Seite, um ihre Bildschirmausrichtung festzulegen

1.3.5 Bestimmung des Eingabezwecks

Stufe AA

Felder, die Informationen über die Nutzenden abfragen, benennen ihren Zweck mit dem richtigen autocomplete-Wert
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie jedes Feld, das Informationen über die Person abfragt, die die Seite nutzt: Name, E-Mail, Telefon, Adresse, Geburtstag, Benutzername, Passwort, Kartendaten.
  2. Lesen Sie bei jedem im Bereich „Elemente“ der Entwicklertools sein autocomplete-Attribut.
  3. Prüfen Sie, ob es den Wert hat, der zur abgefragten Information passt (name, email, tel, street-address, postal-code, bday, username, new-password, cc-number usw.).
  4. Ein Feld mit autocomplete="off" oder ohne autocomplete-Attribut bestimmt seinen Zweck nicht, auch wenn der Browser trotzdem anbietet, es auszufüllen.
  5. Lassen Sie Felder weg, die nach einer anderen Person fragen, etwa nach der Empfängerin oder dem Empfänger eines Geschenks, es sei denn, sie geben dies mit dem richtigen section-Wert oder Wert an.
  6. Nur die Zwecke aus der WCAG-Liste der Eingabezwecke sind relevant. Ein Feld für eine Mitglieds- oder Kundennummer zum Beispiel hat keinen Wert in dieser Liste und braucht keinen.
Bestanden, wenn
Jedes Feld, das eigene Informationen der Nutzenden abfragt, hat den passenden autocomplete-Wert.
Nicht bestanden, wenn
Ein Feld, das eigene Informationen der Nutzenden abfragt, hat keinen oder einen falschen autocomplete-Wert, sodass Browser und Hilfsprogramme es nicht ausfüllen oder seinen Zweck nicht kennzeichnen können; das verstößt gegen WCAG 1.3.5.

Regeln, die es prüfen: autocomplete-valid

Dieser Prüfschritt prüft auch:

  • Ein nicht leeres autocomplete-Attribut hat einen gültigen Autofill-Wert

1.4 Unterscheidbar

1.4.1 Benutzung von Farbe

Stufe A

Farbe ist nicht das einzige Mittel, um Informationen zu zeigen, zu einer Auswahl aufzufordern oder ein Element hervorzuheben
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie nach Informationen, die die Seite über Farbe vermittelt: Links in einem Absatz, Pflichtfelder oder ungültige Felder, der ausgewählte Tab oder Tag, Datenreihen in Diagrammen, Status in Rot oder Grün.
  2. Prüfen Sie bei jeder, ob sie auch durch etwas anderes als Farbe vermittelt wird: eine Unterstreichung, ein Symbol, eine Textbeschriftung, ein Muster, einen Rahmen oder eine Formänderung.
  3. Prüfen Sie bei Links in einem Absatz, die sich nur durch die Farbe unterscheiden, ob sie beim Überfahren mit der Maus und beim Fokussieren eine Unterstreichung oder eine andere Markierung erhalten und ob ihre Farbe einen Kontrast von mindestens 3:1 zum umgebenden Text hat.
  4. Betrachten Sie die Seite in Graustufen (emulieren Sie im Bereich „Rendering“ der Entwicklertools eine Achromatopsie) und prüfen Sie, ob nichts verloren geht.
Bestanden, wenn
Alles, was die Seite über Farbe vermittelt, wird auch auf andere Weise vermittelt.
Nicht bestanden, wenn
Informationen, etwa welche Felder Fehler haben oder welcher Text ein Link ist, werden nur über Farbe vermittelt; das verstößt gegen WCAG 1.4.1.

Regeln, die es prüfen: link-in-text-block

Dieser Prüfschritt prüft auch:

  • Links in Textblöcken sind vom umgebenden Text nicht nur durch Farbe unterscheidbar (Unterstreichung, Unterschied in Schriftstärke oder -stil oder Kontrast >=3:1)

1.4.2 Audio-Steuerelement

Stufe A

Ton, der von selbst länger als 3 Sekunden abgespielt wird, lässt sich pausieren, stoppen oder leiser stellen
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Laden Sie die Seite mit eingeschaltetem Ton und achten Sie auf Ton, der von selbst startet: Musik, ein Video, eine Werbung.
  2. Wird Ton länger als 3 Sekunden abgespielt, suchen Sie oben auf der Seite oder am Player nach einer Möglichkeit, ihn zu pausieren oder zu stoppen oder seine Lautstärke unabhängig von der Systemlautstärke zu verringern.
  3. Prüfen Sie, ob sich das Bedienelement mit der Tastatur finden und bedienen lässt.
Bestanden, wenn
Kein Ton wird von selbst länger als 3 Sekunden abgespielt, oder ein Bedienelement am Anfang der Seite pausiert, stoppt oder verringert ihn.
Nicht bestanden, wenn
Ton wird von selbst länger als 3 Sekunden abgespielt, ohne dass er sich anders als über die Systemlautstärke pausieren, stoppen oder verringern lässt, sodass er einen Screenreader übertönt; das verstößt gegen WCAG 1.4.2.

Regeln, die es prüfen: no-autoplay-audio

1.4.3 Kontrast (Minimum)

Stufe AA

Text hat einen Kontrast von mindestens 4,5:1 zu seinem Hintergrund, bei großem Text 3:1
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie auf der Seite nach Text, der vor seinem Hintergrund blass wirkt: hellgrauer Text, Text auf farbigen Flächen, Platzhalter, Text über Bildern oder Verläufen, Text in Schaltflächen.
  2. Untersuchen Sie jeden und klicken Sie im Bereich „Stile“ der Entwicklertools auf das Farbfeld seiner Farbe: Der Farbwähler zeigt sein Kontrastverhältnis zum Hintergrund.
  3. Der Farbwähler misst gegen die im CSS gesetzte Hintergrundfarbe. Liegt Text auf einem Bild, einem Verlauf oder einer halbtransparenten Ebene oder ergibt sich seine Farbe aus opacity oder einem Mischmodus, ist der Wert des Farbwählers nicht verlässlich: Gehen Sie stattdessen wie im nächsten Schritt vor.
  4. Ist der Hintergrund ein Bild, ein Verlauf oder eine halbtransparente Ebene, messen Sie den Text mit einem Kontrastrechner gegen die Stelle des Hintergrunds, an der er am schlechtesten zu sehen ist.
  5. Prüfen Sie, ob das Verhältnis mindestens 4,5:1 beträgt, bei großem Text 3:1: mindestens 24 Pixel (18 pt) oder 18,66 Pixel (14 pt) und fett.
  6. Runden Sie das Ergebnis nicht: 4,49:1 ist nicht bestanden. Prüfen Sie Text auch in seinen anderen Zuständen, etwa beim Überfahren mit der Maus, bei Fokus und bei Auswahl, da ein Zustand den Kontrast verringern kann.
  7. Lassen Sie Logos und Markennamen weg, Text auf deaktivierten Bedienelementen, Text, der nur Dekoration ist oder den niemand sehen kann, und Text, der Teil eines Bildes mit anderen wichtigen Inhalten ist, etwa ein Straßenschild auf einem Foto.
Bestanden, wenn
Alle Texte und Bilder von Text haben einen Kontrast von mindestens 4,5:1 zu ihrem Hintergrund, bei großem Text 3:1.
Nicht bestanden, wenn
Text hat einen geringeren Kontrast zu seinem Hintergrund als 4,5:1 (3:1 bei großem Text), sodass Menschen mit Sehbehinderung ihn nicht lesen können; das verstößt gegen WCAG 1.4.3.

Regeln, die es prüfen: contrast-minimum, contrast-computable

Dieser Prüfschritt prüft auch:

  • Der Textkontrast für 1.4.3 lässt sich aus dem CSS berechnen (keine Mehrdeutigkeit durch Bilder, Verläufe oder Überblendung)

1.4.4 Textgröße ändern

Stufe AA

Text lässt sich ohne Verlust von Inhalt oder Funktion auf 200 % vergrößern
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Der Zoom des Browsers
  1. Zoomen Sie den Browser auf 200 %.
  2. Gehen Sie die ganze Seite durch und prüfen Sie, ob aller Text größer geworden ist und keiner abgeschnitten, überlagert oder verborgen ist.
  3. Nutzen Sie die Bedienelemente, Menüs und Formulare der Seite in dieser Größe und prüfen Sie, ob alle noch funktionieren.
  4. Prüfen Sie auf einem Smartphone, ob Sie die Seite mit zwei Fingern auf 200 % zoomen können. Verwenden Sie Chrome unter Android, wobei die Bedienungshilfe von Chrome, die das Zoomen erzwingt, ausgeschaltet ist: Safari unter iOS ignoriert einen Viewport, der das Zoomen sperrt, und kann diesen Fehler daher verdecken.
  5. Lassen Sie Untertitel und Bilder von Text weg.
Bestanden, wenn
Bei 200 % ist aller Text größer geworden und bleibt lesbar, und alles funktioniert noch.
Nicht bestanden, wenn
Bei 200 % ist Text abgeschnitten, überlappt oder wird nicht größer, ein Bedienelement funktioniert nicht mehr, oder das Zoomen mit zwei Fingern ist gesperrt; das verstößt gegen WCAG 1.4.4.

Regeln, die es prüfen: meta-viewport-zoom-enabled

Dieser Prüfschritt prüft auch:

  • <meta name="viewport"> deaktiviert das Zoomen mit zwei Fingern nicht und begrenzt es nicht auf unter 200 %

1.4.5 Bilder eines Textes

Stufe AA

Text wird als Text gezeigt, nicht in einem Bild, es sei denn, sein Aussehen ist wesentlich, wie bei einem Logo
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie nach Bildern, die Wörter enthalten: Banner, Überschriften, Schaltflächen, Zitate, Menüs.
  2. Versuchen Sie, ein Wort darin mit dem Zeiger auszuwählen, oder untersuchen Sie es: Text, der sich nicht auswählen lässt, steht meist in einem Bild, einer SVG-Zeichnung oder einem canvas.
  3. Fragen Sie sich bei jedem, ob sich dasselbe mit echtem, per CSS gestaltetem Text darstellen ließe.
  4. Lassen Sie Logos und Markennamen weg, Bilder, bei denen das besondere Aussehen des Textes wesentlich ist, etwa eine Schriftprobe, und Bilder von Text, die Nutzende nach ihren Bedürfnissen anpassen können, etwa eine Seite, auf der sie Schriftart, Größe und Farben des Textes im Bild einstellen können.
Bestanden, wenn
Text ist echter Text, oder ein Bild von Text ist ein Logo oder braucht genau sein Aussehen.
Nicht bestanden, wenn
Wörter werden als Bild gezeigt, wo gestalteter Text gleich aussähe, sodass Menschen ihre Größe, Farbe oder Abstände nicht ändern können; das verstößt gegen WCAG 1.4.5.

Regeln, die es prüfen: image-of-text

Dieser Prüfschritt prüft auch:

  • Bilder, die laut Markup wahrscheinlich Text enthalten (<input type="image">, ein <img> eines SVG mit <text>), werden abgefragt (nur Indiz: Text in den Pixeln eines Bildes wird nicht erkannt)

1.4.10 Umfluss (Reflow)

Stufe AA

Bei 320 CSS-Pixeln Breite erfordern Inhalte kein Scrollen in zwei Richtungen, und nichts geht verloren
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.4.11 Nicht-Text-Kontrast

Stufe AA

Die Teile eines Bedienelements, die zeigen, dass es vorhanden ist und in welchem Zustand es ist, haben einen Kontrast von mindestens 3:1
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

Die Teile einer Grafik, die zu ihrem Verständnis nötig sind, haben einen Kontrast von mindestens 3:1
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

1.4.12 Textabstand

Stufe AA

In einem style-Attribut erzwungene Abstände verhindern nicht, dass Text die Abstände der Nutzenden übernimmt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Durchsuchen Sie im Bereich „Elemente“ der Entwicklertools das Markup der Seite (Strg+F oder auf einem Mac Cmd+F) nach !important und notieren Sie jeden Treffer in einem style-Attribut, das line-height, letter-spacing oder word-spacing setzt.
  2. Lesen Sie bei jedem den resultierenden Wert im Tab „Berechnet“ und vergleichen Sie ihn mit dem 1,5-Fachen der Schriftgröße für line-height, dem 0,12-Fachen für letter-spacing und dem 0,16-Fachen für word-spacing.
  3. Ist der Wert niedriger, verkleinern Sie das Fenster auf 320 CSS-Pixel Breite und prüfen Sie, ob dieser Text in mehr als eine Zeile umbricht.
  4. Fügen Sie im Bereich „Stile“ der Entwicklertools eine neue Stilregel für * mit line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important hinzu sowie eine Regel für p mit margin-bottom: 2em !important. Das Element behält seinen eigenen Wert, da sein style-Attribut Vorrang hat.
  5. Prüfen Sie, ob dieser Text abgeschnitten wird, anderen Text überlappt oder verborgen ist.
Bestanden, wenn
Kein style-Attribut erzwingt bei umbrechendem Text Abstände unter diesen Werten, oder der betroffene Text wird mit den angewendeten Abständen weiterhin vollständig angezeigt.
Nicht bestanden, wenn
Ein style-Attribut erzwingt bei umbrechendem Text Abstände unter diesen Werten, sodass ein Bookmarklet oder eine Browsererweiterung die Abstände der Person nicht anwenden kann, und mit diesen Abständen überlappt der Text oder wird abgeschnitten; das verstößt gegen WCAG 1.4.12.

Regeln, die es prüfen: avoid-inline-spacing

Mit den Abständen aus 1.4.12 wird kein Text abgeschnitten oder überlappt (im Browser gemessen)
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Eine Tastatur
  1. Fügen Sie im Bereich „Stile“ der Entwicklertools eine neue Stilregel für * mit line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important hinzu sowie eine Regel für p mit margin-bottom: 2em !important. Im Bereich „Stile“ hinzugefügte Regeln werden nicht durch die Sicherheitsrichtlinie der Seite blockiert.
  2. Scrollen Sie durch die ganze Seite und suchen Sie nach Text, der abgeschnitten wird, anderen Text überlappt oder verschwindet. Text, der Teil eines Bildes ist, zählt nicht.
  3. Tun Sie dies bei den Breiten, die Sie auch sonst testen, einschließlich 320 CSS-Pixeln Breite, wo Text am stärksten umbricht und am häufigsten abgeschnitten wird.
  4. Wird Text abgeschnitten, prüfen Sie, ob die Seite eine Möglichkeit bietet, ihn vollständig anzuzeigen, etwa einen Link „Weiterlesen“ oder eine Schaltfläche, die den Kasten aufklappt. Das zählt nur, wenn Sie sie mit der Tastatur bedienen können und sie bei weiterhin angewendeten Abständen den ganzen Text zeigt.
Bestanden, wenn
Aller Text bleibt sichtbar und lesbar, oder abgeschnittener Text lässt sich mit der Tastatur vollständig anzeigen.
Nicht bestanden, wenn
Mit den angewendeten Abständen wird Text abgeschnitten, überlappt oder geht verloren und lässt sich auch nicht auf andere Weise vollständig anzeigen; das verstößt gegen WCAG 1.4.12.

Regeln, die es prüfen: text-spacing-content-loss

Mit den Abständen aus 1.4.12 funktionieren Bedienelemente, Menüs und Formulare weiter und zeigen ihren ganzen Text
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Die Entwicklertools des Browsers, Eine Tastatur, Eine Maus oder ein anderes Zeigegerät
  1. Fügen Sie im Bereich „Stile“ der Entwicklertools eine neue Stilregel für * mit line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important hinzu sowie eine Regel für p mit margin-bottom: 2em !important.
  2. Bedienen Sie jedes Bedienelement der Seite: Öffnen Sie ihre Menüs und Auswahllisten, füllen Sie ihre Formulare aus und senden Sie sie ab, wechseln Sie ihre Tabs und öffnen und schließen Sie ihre Dialoge.
  3. Prüfen Sie, ob jedes noch reagiert, ob kein verschobener Text ein Bedienelement verdeckt und ob jede Beschriftung und jede Schaltfläche ihren ganzen Text zeigt.
Bestanden, wenn
Jedes Bedienelement funktioniert mit den angewendeten Abständen weiter und zeigt seinen ganzen Text.
Nicht bestanden, wenn
Mit den angewendeten Abständen funktioniert ein Bedienelement nicht mehr, ist so verdeckt, dass es sich nicht bedienen lässt, oder verliert Text, der sagt, was es tut; das verstößt gegen WCAG 1.4.12.
Mit den Abständen aus 1.4.12 behalten Inhalte, die erst nach einer Interaktion erscheinen (Menüs, Dialoge, Tabs, Meldungen), ihren ganzen Text
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Die Entwicklertools des Browsers, Eine Tastatur, Eine Maus oder ein anderes Zeigegerät
  1. Fügen Sie im Bereich „Stile“ der Entwicklertools eine neue Stilregel für * mit line-height: 1.5 !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important hinzu sowie eine Regel für p mit margin-bottom: 2em !important.
  2. Rufen Sie die Inhalte auf, die die Seite erst zeigt, wenn Sie etwas tun: Öffnen Sie jedes Menü und jeden Dialog, wechseln Sie zu jedem Tab, klappen Sie jeden eingeklappten Abschnitt auf, lassen Sie jeden Tooltip anzeigen und senden Sie ein Formular mit einem Fehler ab, um seine Fehlermeldungen zu sehen.
  3. Prüfen Sie jeden wie auf der Seite selbst auf Text, der abgeschnitten wird, anderen Text überlappt oder verschwindet.
  4. Wird Text abgeschnitten, prüfen Sie, ob die Seite eine Möglichkeit bietet, ihn vollständig anzuzeigen, etwa einen Link „Weiterlesen“ oder eine Schaltfläche, die den Kasten aufklappt. Das zählt nur, wenn Sie sie mit der Tastatur bedienen können und sie bei weiterhin angewendeten Abständen den ganzen Text zeigt.
Bestanden, wenn
Inhalte, die erscheinen, nachdem Sie etwas tun, behalten mit den angewendeten Abständen ihren ganzen Text sichtbar und lesbar, oder abgeschnittener Text lässt sich mit der Tastatur vollständig anzeigen.
Nicht bestanden, wenn
Text in einem Menü, Dialog, Tab, Tooltip oder einer Meldung wird mit den angewendeten Abständen abgeschnitten oder überlappt und lässt sich nicht auf andere Weise vollständig anzeigen; das verstößt gegen WCAG 1.4.12.

1.4.13 Inhalt bei Überfahren mit dem Zeiger oder Tastaturfokus („Hover“ oder „Focus“)

Stufe AA

Zusätzliche Inhalte, die bei Hover oder Fokus erscheinen, lassen sich schließen, ohne Zeiger oder Fokus zu bewegen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

Der Zeiger kann auf zusätzliche Inhalte, die bei Hover erscheinen, bewegt werden, ohne dass sie verschwinden
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

Zusätzliche Inhalte, die bei Hover oder Fokus erscheinen, bleiben sichtbar, bis sie geschlossen werden, Zeiger oder Fokus sich entfernen oder sie nicht mehr zutreffen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2 Bedienbar

2.1 Per Tastatur zugänglich

2.1.1 Tastatur

Stufe A

Alle Funktionen lassen sich allein mit der Tastatur bedienen
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Schalten Sie jeden Screenreader aus. Im Lesemodus kann ein Screenreader Elemente aktivieren, die mit der Tastatur allein nicht erreichbar sind, und so Fehler verdecken.
  2. Laden Sie die Seite neu und drücken Sie, ohne zu klicken, wiederholt Tab durch die ganze Seite. Notieren Sie jeden Link, jede Schaltfläche, jedes Feld und jedes andere Bedienelement, an dem Sie vorbeikommen.
  3. Vergleichen Sie das mit dem, was Sie mit dem Zeiger anklicken oder ziehen können, und notieren Sie alles, was die Tastatur nie erreicht: ein Bedienelement, einen Menüeintrag, einen scrollbaren Kasten, einen Teil einer Karte oder ein benutzerdefiniertes Widget.
  4. Bedienen Sie jedes Bedienelement mit der Tastatur: Eingabetaste oder Leertaste zum Aktivieren, Pfeiltasten in Menüs, Tabs, Listen und Schiebereglern, Esc zum Schließen dessen, was sich öffnet.
  5. Vergleichen Sie bei benutzerdefinierten Widgets die Tasten mit denen, die die WAI-ARIA Authoring Practices für diese Art von Widget angeben, etwa die Pfeiltasten in einer Tab-Liste. Ein Widget, das nur mit ungewöhnlichen Tasten funktioniert, kann dieses Kriterium trotzdem erfüllen, wenn die Seite die Tasten erklärt, aber halten Sie es als Problem der Gebrauchstauglichkeit fest.
  6. Lässt sich etwas mit der Tastatur nicht erreichen oder bedienen, prüfen Sie, ob die Seite einen anderen Weg bietet, dasselbe allein mit der Tastatur zu tun, etwa Schaltflächen „Zurück“ und „Weiter“ für ein Karussell. Das zählt nur, wenn dieser Weg alles leistet, was der Zeiger kann.
  7. Lassen Sie weg, was vom Weg des Zeigers abhängt, etwa Freihandzeichnen.
Bestanden, wenn
Alles, was die Seite mit einem Zeiger ermöglicht, lässt sich allein mit der Tastatur erledigen, direkt oder über einen anderen Weg, der dasselbe leistet.
Nicht bestanden, wenn
Etwas lässt sich nur mit einem Zeiger erledigen, ohne einen Tastaturweg für dasselbe; das verstößt gegen WCAG 2.1.1.

Regeln, die es prüfen: iframe-focusable-content, server-side-image-map-absent, scrollable-region-focusable, mouse-only-event-handlers, click-handler-keyboard-operable, widget-keyboard-focusable, focus-not-removed-by-script

Dieser Prüfschritt prüft auch:

  • Frames desselben Ursprungs mit tabindex="-1" enthalten keine fokussierbaren Inhalte
  • <img> verwendet keine serverseitige Imagemap (ismap)
  • Ein per CSS scrollbarer Bereich ohne fokussierbare Nachfahren ist selbst per Tastatur fokussierbar (nur Indiz: der tatsächliche Überlauf ist statisch nicht ermittelbar)
  • Inline-Event-Handler nur für Zeiger haben eine per Tastatur erreichbare Entsprechung (nur Indiz: per JS angehängte Listener sind statisch nicht sichtbar)
  • Ein Inline-Klick-Handler an einem Element, das kein natives Bedienelement ist, lässt sich per Tastatur erreichen und auslösen
  • Ein Element mit einer Widget-Rolle oder ein Eintrag eines zusammengesetzten Widgets ist in der Tab-Reihenfolge (nur Indiz: ein Skript kann den Fokus auf eine Weise bewegen, die das Markup nicht zeigt)
  • Ein Inline-Fokus-Handler entfernt den Fokus nicht von dem Element, das ihn erhält (nur Indiz: per Skript hinzugefügte Listener sind statisch nicht sichtbar)

2.1.2 Keine Tastaturfalle

Stufe A

Der Fokus lässt sich von jedem Teil der Seite mit der Tastatur wieder wegbewegen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.1.4 Zeichentastenbefehle

Stufe A

Tastaturkürzel aus einem einzelnen Buchstaben, einer Ziffer oder einem Symbol lassen sich ausschalten oder neu zuweisen oder funktionieren nur, solange ihr Bedienelement den Fokus hat
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.2 Ausreichend Zeit

2.2.1 Zeiteinteilung anpassbar

Stufe A

Jede Zeitbegrenzung lässt sich ausschalten, anpassen oder verlängern, sofern sie nicht in Echtzeit abläuft, wesentlich ist oder 20 Stunden überschreitet
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: nur ein Browser
  1. Suchen Sie auf der Seite nach allem, was nach einer festgelegten Zeit geschieht: eine Sitzung, die endet, ein Formular, das abläuft, eine Seite, die sich von selbst aktualisiert oder weiterschaltet, Inhalte, die verschwinden.
  2. Prüfen Sie den Quelltext der Seite und warten Sie eine Weile auf ihr, um Begrenzungen zu finden, die nicht angekündigt werden, etwa ein <meta http-equiv="refresh"> oder eine Abmeldung nach Inaktivität.
  3. Fragen Sie bei einer Sitzung, die auf dem Server endet, das Team, wie lange sie dauert, statt zu raten, und warten Sie dann zu diesem Zeitpunkt auf die Warnung. Prüfen Sie die Warnung mit einem Screenreader: Sie muss angesagt und nicht nur angezeigt werden.
  4. Prüfen Sie bei jeder Begrenzung, ob mindestens eine dieser Bedingungen zutrifft: Sie können sie ausschalten, bevor Sie sie erreichen; Sie können sie auf mindestens das Zehnfache ihrer Dauer anpassen; oder Sie werden gewarnt, bevor sie abläuft, haben mindestens 20 Sekunden, um sie mit einer einfachen Aktion wie einem Tastendruck zu verlängern, und können sie mindestens zehnmal verlängern.
  5. Lassen Sie Begrenzungen weg, die Teil eines Echtzeitereignisses wie einer Auktion sind, die wesentlich sind wie bei einer zeitgebundenen Prüfung oder die länger als 20 Stunden sind.
Bestanden, wenn
Jede Zeitbegrenzung lässt sich ausschalten, anpassen oder verlängern, oder sie läuft in Echtzeit ab, ist wesentlich oder länger als 20 Stunden.
Nicht bestanden, wenn
Eine Zeitbegrenzung beendet eine Sitzung, ein Formular oder eine Seite, ohne dass sie sich ausschalten, anpassen oder verlängern lässt; das verstößt gegen WCAG 2.2.1.

Regeln, die es prüfen: meta-refresh-timing-absent

Dieser Prüfschritt prüft auch:

  • <meta http-equiv="refresh"> erzwingt keine verzögerte Aktualisierung der Seite

2.2.2 Pausieren, beenden, ausblenden

Stufe A

Animationen, die von selbst starten und länger als fünf Sekunden dauern, lassen sich pausieren, beenden oder ausblenden
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Laden Sie die Seite und achten Sie auf alles, was sich von selbst bewegt, blinkt oder scrollt: Karussells, Lauftext, Animationen, Hintergrundvideos.
  2. Suchen Sie bei allem, was von selbst startet, länger als 5 Sekunden dauert und neben anderen Inhalten angezeigt wird, nach einem Bedienelement, um es zu pausieren, zu beenden oder auszublenden.
  3. Prüfen Sie, ob sich das Bedienelement mit der Tastatur finden und bedienen lässt und ob es die Bewegung anhält, statt sie nur zu verlangsamen.
  4. Lassen Sie wesentliche Bewegung weg, etwa eine Fortschrittsanzeige, während etwas lädt.
Bestanden, wenn
Alles, was sich neben anderen Inhalten länger als 5 Sekunden von selbst bewegt, blinkt oder scrollt, lässt sich pausieren, beenden oder ausblenden.
Nicht bestanden, wenn
Inhalte bewegen sich, blinken oder scrollen neben anderen Inhalten länger als 5 Sekunden von selbst, ohne dass sie sich pausieren, beenden oder ausblenden lassen; das verstößt gegen WCAG 2.2.2.

Regeln, die es prüfen: moving-content-pausable, deprecated-elements-not-used

Dieser Prüfschritt prüft auch:

  • Veraltete, nicht anhaltbare Elemente (<blink>, <marquee>) sind nicht vorhanden
Inhalte, die sich von selbst aktualisieren, lassen sich pausieren, beenden, ausblenden oder seltener aktualisieren
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Achten Sie auf der Seite auf Inhalte, die sich von selbst ändern: Nachrichtenticker, Live-Ergebnisse, Preise, Feeds, Timer.
  2. Suchen Sie bei allem, was von selbst startet und neben anderen Inhalten angezeigt wird, nach einem Bedienelement, um es zu pausieren, zu beenden oder auszublenden oder um festzulegen, wie oft es sich aktualisiert.
  3. Prüfen Sie, ob sich das Bedienelement mit der Tastatur finden und bedienen lässt.
  4. Lassen Sie Aktualisierungen weg, die für den Zweck der Seite wesentlich sind.
Bestanden, wenn
Jeder Teil, der sich neben anderen Inhalten von selbst aktualisiert, lässt sich pausieren, beenden, ausblenden oder verlangsamen, oder seine Aktualisierungen sind wesentlich.
Nicht bestanden, wenn
Inhalte aktualisieren sich neben anderen Inhalten von selbst, ohne dass sie sich pausieren, beenden oder ausblenden lassen oder sich ändern lässt, wie oft; das verstößt gegen WCAG 2.2.2.

2.3 Anfälle und physische Reaktionen

2.3.1 Grenzwert von dreimaligem Blitzen oder weniger

Stufe A

Nichts blitzt öfter als dreimal in einer Sekunde, oder die Blitze sind klein und schwach genug
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.4 Navigierbar

2.4.1 Blöcke umgehen

Stufe A

Blöcke, die sich auf mehreren Seiten wiederholen, lassen sich überspringen
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Eine Tastatur, Ein Screenreader, Die Entwicklertools des Browsers
  1. Schließen Sie alle Dialoge und Overlays und notieren Sie dann die Blöcke, die die Seite von anderen Seiten der Website wiederholt: Kopfbereich, Navigation, Suche, Seitenleisten.
  2. Laden Sie die Seite neu und drücken Sie einmal Tab: Prüfen Sie, ob ein Sprunglink erscheint, der den Fokus an diesen Blöcken vorbei zum Hauptinhalt bewegt, und folgen Sie ihm mit der Eingabetaste.
  3. Prüfen Sie im Bereich „Barrierefreiheit“ der Entwicklertools oder in den Listen eines Screenreaders, ob der Hauptinhalt eine main-Landmarke ist oder mit einer Überschrift außerhalb der Navigation beginnt.
  4. Hat die Seite einen Sprunglink, prüfen Sie, ob sein Ziel existiert und ob das nächste Tab, nachdem Sie ihm gefolgt sind, in den Hauptinhalt führt.
Bestanden, wenn
Die Seite wiederholt keine Blöcke, oder ein funktionierender Sprunglink, eine main-Landmarke oder Überschriften ermöglichen es Tastatur- und Screenreader-Nutzenden, sie zu überspringen.
Nicht bestanden, wenn
Wiederholte Blöcke lassen sich nicht überspringen, sodass Tastatur- und Screenreader-Nutzende sie auf jeder Seite durchlaufen müssen; das verstößt gegen WCAG 2.4.1.

Regeln, die es prüfen: bypass-blocks-present

2.4.2 Seite mit Titel versehen

Stufe A

Die Seite hat einen Titel, der sagt, worum es geht oder wofür sie dient, und sie von den anderen Seiten der Website unterscheidet
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: nur ein Browser
  1. Lesen Sie den Titel der Seite im Browser-Tab oder im <title> im Bereich „Elemente“ der Entwicklertools.
  2. Prüfen Sie, ob er sagt, worum es auf dieser Seite geht oder wofür sie dient, etwa die Schlagzeile des Artikels oder den Schritt eines Prozesses („Lieferadresse - Kasse - Shop“).
  3. Öffnen Sie zwei oder drei andere Seiten der Website und prüfen Sie, ob ihre Titel die Seiten unterscheiden. Den seitenspezifischen Teil vor den Namen der Website zu stellen, ist gute Praxis, aber nicht erforderlich.
  4. Ändert die Seite ihren Inhalt, ohne eine neue Seite zu laden, wie es eine Einzelseitenanwendung (SPA) tut, prüfen Sie, ob sich der Titel mit ändert.
Bestanden, wenn
Der Titel der Seite sagt, worum es geht oder wofür sie dient, und unterscheidet sie von anderen Seiten.
Nicht bestanden, wenn
Die Seite hat keinen Titel oder einen, der allgemein ist, ein Dateiname ist oder dem anderer Seiten gleicht; das verstößt gegen WCAG 2.4.2.

Regeln, die es prüfen: page-title-present, page-title-patterns

Dieser Prüfschritt prüft auch:

  • Ein <title>-Element ist vorhanden und nicht leer
  • Prüfung der Muster von Seitentiteln (allgemein / doppelt / über Seiten hinweg zu stark nach Vorlage)

2.4.3 Fokus-Reihenfolge

Stufe A

Das Bewegen des Fokus mit Tab und Umschalttaste+Tab folgt einer Reihenfolge, die die Bedeutung der Seite erhält und ihre Bedienung ermöglicht
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Laden Sie die Seite neu und drücken Sie wiederholt Tab, bis der Fokus die ganze Seite durchlaufen hat, und beobachten Sie, wohin er geht.
  2. Vergleichen Sie die Reihenfolge mit der, in der Sie die Seite lesen und nutzen würden: zum Beispiel die Felder eines Formulars in der Reihenfolge ihrer Beschriftungen und die Schritte einer Aufgabe in ihrer Abfolge.
  3. Drücken Sie Umschalttaste+Tab zurück durch die Seite und prüfen Sie, ob der Fokus denselben Weg in umgekehrter Richtung nimmt.
  4. Weicht die Reihenfolge von der Lesereihenfolge ab, prüfen Sie, ob das die Bedeutung von etwas ändert oder Sie an der Bedienung hindert, etwa wenn Sie die Schaltfläche „Absenden“ eines Formulars vor seinen Feldern erreichen.
Bestanden, wenn
Der Fokus bewegt sich in einer Reihenfolge durch die Seite, die ihre Bedeutung erhält und jeden Teil bedienbar macht, auch wo sie geringfügig von der visuellen Reihenfolge abweicht.
Nicht bestanden, wenn
Der Fokus springt so auf der Seite umher, dass sich ihre Bedeutung oder Bedienung ändert, etwa weil Felder außerhalb ihrer Reihenfolge ausgefüllt werden; das verstößt gegen WCAG 2.4.3.
Der Fokus geht in einen Dialog, ein Menü oder einen Abschnitt, der sich öffnet, bleibt im Dialog, solange dieser die Seite überdeckt, und kehrt beim Schließen zurück
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur
  1. Öffnen Sie mit der Tastatur jeden Dialog, jedes Menü, jede Auswahlliste und jeden eingeklappten Abschnitt der Seite, indem Sie auf dem Bedienelement, das ihn öffnet, die Eingabetaste oder die Leertaste drücken.
  2. Drücken Sie einmal Tab und prüfen Sie, ob der Fokus in das Geöffnete geht oder bereits darin ist, statt zu etwas dahinter oder weit davon entfernt.
  3. Drücken Sie in einem Dialog, der die Seite überdeckt, Tab, bis Sie alle seine Bedienelemente durchlaufen haben, und prüfen Sie, ob der Fokus im Dialog bleibt, statt zur Seite dahinter zu gehen.
  4. Schließen Sie ihn mit Esc oder seiner Schließen-Schaltfläche und prüfen Sie, ob der Fokus zu dem Bedienelement zurückkehrt, das ihn geöffnet hat, oder an die nächste sinnvolle Stelle.
Bestanden, wenn
Der Fokus geht in das, was sich öffnet, bleibt in einem Dialog, solange dieser die Seite überdeckt, und kehrt beim Schließen dorthin zurück, wo er war.
Nicht bestanden, wenn
Der Fokus bleibt hinter dem, was sich öffnet, verlässt einen Dialog zur Seite dahinter oder landet beim Schließen am Anfang der Seite, sodass die Reihenfolge nicht mehr dem Bildschirm folgt; das verstößt gegen WCAG 2.4.3.
Der Fokus hält nicht an Inhalten, die geschlossen, verborgen oder außerhalb des Bildschirms sind
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Eine Tastatur, Die Entwicklertools des Browsers
  1. Schließen Sie alle Menüs und Dialoge, laden Sie die Seite neu und drücken Sie dann Tab durch die ganze Seite, wobei Sie beobachten, wo der Fokus ist.
  2. Notieren Sie jedes Mal, wenn der Fokus für einen oder mehrere Tastendrücke zu verschwinden scheint.
  3. Geben Sie an jeder solchen Stelle document.activeElement in der Konsole der Entwicklertools ein und prüfen Sie, ob das angezeigte Element in einem geschlossenen Menü, einem verborgenen Bereich oder außerhalb des Bildschirms liegt.
  4. Lassen Sie einen Sprunglink weg, der erscheint, wenn er den Fokus erhält: Er wird angezeigt, sobald er fokussiert ist.
Bestanden, wenn
Jeder Tab-Stopp liegt auf etwas, das Sie sehen können, oder auf etwas, das erscheint, wenn es den Fokus erhält, etwa einem Sprunglink.
Nicht bestanden, wenn
Der Fokus hält an Bedienelementen in geschlossenen Menüs, verborgenen Bereichen oder außerhalb des Bildschirms, sodass die Reihenfolge durch Dinge führt, die nicht zu sehen sind; das verstößt gegen WCAG 2.4.3.

2.4.4 Linkzweck (im Kontext)

Stufe A

  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Listen Sie die Links der Seite über die Linkliste eines Screenreaders auf oder gehen Sie sie mit Tab durch und lesen Sie bei jedem den Eintrag „Name“ im Bereich „Barrierefreiheit“ der Entwicklertools.
  2. Notieren Sie Links, deren Name nicht sagt, wohin sie führen oder was sie tun: leere Namen, „hier klicken“, „mehr lesen“, „PDF“, der Dateiname eines Symbols.
  3. Lesen Sie bei jedem den Satz, Absatz, Listeneintrag oder die Tabellenzelle, in dem der Link steht, oder die Tabellenüberschrift seiner Zelle, und prüfen Sie, ob das seinen Zweck klar macht.
  4. Als Kontext zählen der Satz, Absatz, Listeneintrag oder die Tabellenzelle des Links, die Kopfzellen seiner Tabellenzelle, die Überschrift, unter der der Link steht, und Text, der über aria-describedby mit dem Link verknüpft ist. Text, der nur in der Nähe des Links steht, etwa ein Absatz in einer anderen Spalte, zählt nicht.
  5. Prüfen Sie, ob Links mit demselben Namen, die zu unterschiedlichen Zielen führen, durch ihren Kontext unterscheidbar sind.
Bestanden, wenn
Der Zweck jedes Links geht aus seinem Namen hervor oder aus seinem Namen zusammen mit dem Satz, Absatz, Listeneintrag oder der Tabellenzelle, in dem er steht.
Nicht bestanden, wenn
Ein Link hat keinen Namen oder einen Namen wie „mehr lesen“, dessen Zweck nichts in seinem Umfeld erklärt; das verstößt gegen WCAG 2.4.4.

Regeln, die es prüfen: link-name-present, link-name-quality

Dieser Prüfschritt prüft auch:

  • Links stellen einen zugänglichen Namen bereit (bei einem Link ohne Namen lässt sich kein Zweck bestimmen)
  • Der Linktext ist keine bekannte nichtssagende oder allgemeine Formulierung (nur Indiz: ob der umgebende Kontext ausreicht, wird nicht geprüft)

2.4.5 Verschiedene Methoden

Stufe AA

Es gibt mehr als einen Weg, eine Seite innerhalb der Website zu finden
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.4.6 Überschriften und Beschriftungen (Labels)

Stufe AA

Überschriften beschreiben die Inhalte, die ihnen folgen
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Ein Screenreader
  1. Listen Sie die Überschriften der Seite über die Überschriftenliste eines Screenreaders, eine Browsererweiterung wie HeadingsMap oder den Barrierefreiheitsbaum der Entwicklertools auf.
  2. Lesen Sie jede Überschrift und die Inhalte darunter.
  3. Prüfen Sie, ob jede Überschrift sagt, worum es in diesen Inhalten geht, und kein Platzhalter, kein Dateiname und kein Wort ist, das über allem stehen könnte.
  4. Prüfen Sie, ob benachbarte Überschriften derselben Ebene unterscheidbar sind.
  5. Dieses Kriterium verlangt nur, dass vorhandene Überschriften und Beschriftungen ihren Inhalt beschreiben. Eine fehlende Überschrift oder Beschriftung wird unter 1.3.1 oder 3.3.2 geprüft, nicht hier.
Bestanden, wenn
Jede Überschrift sagt, worum es in den Inhalten darunter geht.
Nicht bestanden, wenn
Eine Überschrift beschreibt die Inhalte darunter nicht, etwa „Abschnitt 1“ oder ein Dateiname; das verstößt gegen WCAG 2.4.6.

Regeln, die es prüfen: heading-quality

Beschriftungen beschreiben ihre Felder, und Felder mit derselben Beschriftung sind unterscheidbar
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: nur ein Browser
  1. Lesen Sie die sichtbare Beschriftung jedes Feldes und Bedienelements auf der Seite.
  2. Prüfen Sie, ob jede sagt, was einzugeben oder zu wählen ist, etwa „E-Mail-Adresse“ statt „Feld 1“ oder „Text“.
  3. Teilen sich mehrere Felder eine Beschriftung, etwa zweimal „Name“, prüfen Sie, ob die Seite klar macht, welches welches ist, durch eine Gruppenüberschrift oder den Rest der Beschriftung.
Bestanden, wenn
Jede Beschriftung sagt, wofür ihr Feld oder Bedienelement dient, und Felder mit derselben Beschriftung sind unterscheidbar.
Nicht bestanden, wenn
Eine Beschriftung sagt nicht, wofür ihr Feld dient, oder mehrere Felder haben dieselbe Beschriftung, ohne dass etwas sie unterscheidet; das verstößt gegen WCAG 2.4.6.

Regeln, die es prüfen: form-control-label-quality

2.4.7 Fokus sichtbar

Stufe AA

Jedes Element, das den Tastaturfokus erhält, zeigt an, dass es ihn hat
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Eine Tastatur
  1. Laden Sie die Seite neu und drücken Sie langsam Tab durch die ganze Seite.
  2. Prüfen Sie an jedem Halt, ob Sie sehen können, welches Element den Fokus hat: ein Umriss, eine Farbänderung, eine Unterstreichung oder eine andere sichtbare Änderung.
  3. Bewegen Sie den Fokus mit der Tastatur, nicht mit der Maus. Browser zeigen den Fokus eines mit der Maus angeklickten Elements anders an als den eines mit Tab erreichten, daher beweist ein Test mit der Maus hier nichts.
  4. Notieren Sie jeden Halt, an dem Sie nicht erkennen, wo der Fokus ist, und jedes Mal, wenn der Fokus für einen oder mehrere Tastendrücke zu verschwinden scheint.
  5. Gehen Sie in Menüs, Dialogen und Widgets, die die Pfeiltasten verwenden, ebenso vor.
  6. Aktivieren Sie in Windows ein Kontrastdesign und wiederholen Sie einige Halte. Ein Fokusstil, der nur mit box-shadow oder einer Hintergrundfarbe gezeichnet ist, verschwindet in diesem Modus. WCAG verlangt nicht, dass er dort sichtbar ist, aber halten Sie es als Best-Practice-Befund fest.
Bestanden, wenn
An jedem Halt ist zu sehen, welches Element den Fokus hat.
Nicht bestanden, wenn
Der Fokus erreicht ein Element ohne sichtbare Änderung oder landet auf etwas Verborgenem oder außerhalb des Bildschirms, sodass Tastaturnutzende nicht mehr wissen, wo sie sind; das verstößt gegen WCAG 2.4.7.

Regeln, die es prüfen: css-hidden-focus, css-focus-indicator-suppressed, focus-not-removed-by-script

Dieser Prüfschritt prüft auch:

  • Ein per Tab erreichbares Element ist per CSS visuell verborgen
  • CSS entfernt den Fokusindikator nicht, ohne einen Ersatz zu zeichnen
  • Ein Inline-Fokus-Handler entfernt den Fokus nicht von dem Element, das ihn erhält (nur Indiz: per Skript hinzugefügte Listener sind statisch nicht sichtbar)

2.4.11 Fokus nicht verdeckt (Minimum)

Stufe AA

Ein Element, das den Fokus erhält, wird nicht vollständig von Inhalten verdeckt, die die Seite darüberlegt
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.5 Eingabemodalitäten

2.5.1 Zeigergesten

Stufe A

Was eine pfadbasierte Geste oder Mehrpunktgeste bewirkt, lässt sich auch mit einem einzelnen Tippen oder Klicken erledigen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.5.2 Zeigeraufhebung

Stufe A

Aktionen werden beim Loslassen des Zeigers ausgeführt, nicht beim Drücken, oder lassen sich abbrechen oder rückgängig machen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.5.3 Beschriftung (Label) im Namen

Stufe A

Der Name eines Bedienelements enthält den Text seiner sichtbaren Beschriftung
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie jedes Bedienelement mit einer sichtbaren Beschriftung aus Text: Schaltflächen, Links, Felder, Tabs, Menüeinträge und Bedienelemente, die durch Text daneben beschriftet sind.
  2. Lesen Sie bei jedem den Eintrag „Name“ im Bereich „Barrierefreiheit“ der Entwicklertools.
  3. Prüfen Sie, ob der Name die Wörter der sichtbaren Beschriftung in derselben Reihenfolge enthält, idealerweise am Anfang (eine Schaltfläche mit „Senden“ heißt „Nachricht senden“, nicht „Absenden“).
  4. Ignorieren Sie beim Vergleich Unterschiede in Groß-/Kleinschreibung und Satzzeichen. Als Bild dargestellter Text zählt ebenfalls als sichtbare Beschriftung.
  5. Lassen Sie eine Beschriftung weg, die nur aus Symbolen besteht, etwa „ד oder „>“: Der Name sollte sagen, was das Bedienelement tut.
  6. Lassen Sie Bedienelemente ohne sichtbaren Text weg, etwa eine Schaltfläche, die nur aus einem Symbol besteht: Sie haben keine sichtbare Beschriftung, mit der verglichen werden kann.
Bestanden, wenn
Der Name jedes Bedienelements enthält die Wörter seiner sichtbaren Beschriftung in ihrer Reihenfolge.
Nicht bestanden, wenn
Der Name eines Bedienelements enthält seine sichtbare Beschriftung nicht, sodass jemand, der Spracheingabe nutzt, es nicht aktivieren kann, indem er sagt, was er sieht; das verstößt gegen WCAG 2.5.3.

Regeln, die es prüfen: label-in-name

2.5.4 Auslösen durch Bewegung

Stufe A

Was durch Bewegen des Geräts ausgelöst wird, lässt sich auch mit Bedienelementen erledigen, und die Reaktion auf Bewegung lässt sich ausschalten
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.5.7 Ziehbewegungen

Stufe AA

Was durch Ziehen erledigt wird, lässt sich auch mit einzelnem Tippen oder Klicken erledigen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

2.5.8 Zielgröße (Minimum)

Stufe AA

Ziele sind mindestens 24 mal 24 CSS-Pixel groß oder weit genug voneinander entfernt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie nach kleinen Bedienelementen: Symbole, Schließen-Schaltflächen, Seitennavigation, Links in einer Reihe, kleine Kontrollkästchen.
  2. Untersuchen Sie jedes und lesen Sie im Boxmodell der Entwicklertools die Größe des Bereichs ab, der auf den Zeiger reagiert und größer als das sichtbare Symbol sein kann. Prüfen Sie, ob er mindestens 24 mal 24 CSS-Pixel groß ist.
  3. Ist er kleiner, prüfen Sie, ob ein Kreis mit 24 Pixeln Durchmesser, der darauf zentriert ist, ein anderes Ziel oder den Kreis eines anderen kleinen Ziels berühren würde.
  4. Lassen Sie Links in einem Satz oder Absatz weg, Bedienelemente, die der Browser ungestaltet zeichnet, Bedienelemente mit einer Entsprechung in voller Größe an anderer Stelle der Seite und Ziele, deren Größe wesentlich ist, etwa die Markierungen auf einer Karte.
Bestanden, wenn
Jedes Ziel ist mindestens 24 mal 24 CSS-Pixel groß, weit genug von anderen entfernt oder fällt unter eine der Ausnahmen.
Nicht bestanden, wenn
Ein Ziel, das kleiner als 24 mal 24 CSS-Pixel ist, liegt so nah an einem anderen, dass sich ihre 24-Pixel-Kreise überschneiden, ohne dass eine Ausnahme greift; das verstößt gegen WCAG 2.5.8.

Regeln, die es prüfen: target-size-minimum

3 Verständlich

3.1 Lesbar

3.1.1 Sprache der Seite

Stufe A

Die Hauptsprache der Seite ist im Markup angegeben und ist die richtige
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Lesen Sie das lang-Attribut des <html>-Elements im Bereich „Elemente“ der Entwicklertools.
  2. Prüfen Sie, ob es ein Sprachcode ist (en, fr, pt-BR) und ob es die Sprache ist, in der der größte Teil des Textes der Seite steht.
  3. Hat <html> auch xml:lang, prüfen Sie, ob beide dieselbe Sprache angeben.
  4. Ändern Sie in einer Einzelseitenanwendung (SPA) die Sprache der Oberfläche und prüfen Sie, ob sich lang mit ändert. Ein Screenreader wechselt die Stimme nur, wenn eine für diese Sprache installiert ist, beurteilen Sie daher das Markup und nicht nur, was Sie hören.
Bestanden, wenn
Das lang des <html>-Elements gibt die Sprache an, in der der größte Teil der Seite steht.
Nicht bestanden, wenn
Die Seite hat kein lang oder ein falsches oder ungültiges, sodass Screenreader sie mit der falschen Stimme und Aussprache vorlesen; das verstößt gegen WCAG 3.1.1.

Regeln, die es prüfen: html-lang-attr-present, html-xml-lang-mismatch

Dieser Prüfschritt prüft auch:

  • <html> hat ein gültiges, nicht leeres lang-Attribut
  • lang und xml:lang an <html> geben dieselbe Hauptsprache an, wenn beide vorhanden sind

3.1.2 Sprache von Teilen

Stufe AA

Passagen und Ausdrücke in einer anderen Sprache als der der Seite sind mit ihrer eigenen Sprache ausgezeichnet
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Lesen Sie die Seite durch und notieren Sie Passagen, Zitate, Ausdrücke und Bezeichnungen, die in einer anderen Sprache als der der Seite geschrieben sind, einschließlich der Optionen einer Sprachauswahl.
  2. Prüfen Sie bei jeder im Bereich „Elemente“ der Entwicklertools, ob sie oder ein umgebendes Element ein lang-Attribut mit dem Code dieser Sprache hat.
  3. Lassen Sie Eigennamen, Fachbegriffe und Wörter weg, die Teil der Sprache der Seite geworden sind, etwa „café“ im Englischen.
  4. Hören Sie sich einige davon mit einem Screenreader an, um zu prüfen, ob er die Aussprache wechselt.
Bestanden, wenn
Jede Passage und jeder Ausdruck in einer anderen Sprache ist mit einem gültigen lang-Attribut für diese Sprache ausgezeichnet.
Nicht bestanden, wenn
Eine Passage oder ein Ausdruck in einer anderen Sprache ist nicht oder mit einem falschen Code ausgezeichnet, sodass sie mit der falschen Aussprache vorgelesen wird; das verstößt gegen WCAG 3.1.2.

Regeln, die es prüfen: valid-lang

Dieser Prüfschritt prüft auch:

  • Das lang-Attribut jedes Elements ist, sofern vorhanden, ein syntaktisch gültiges Sprach-Tag

3.2 Vorhersehbar

3.2.1 Bei Fokus

Stufe A

Das Bewegen des Fokus auf ein Element ändert nicht von selbst den Kontext
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.2.2 Bei Eingabe

Stufe A

Das Ändern einer Einstellung ändert den Kontext nicht, es sei denn, Nutzende werden vorher darauf hingewiesen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.2.3 Konsistente Navigation

Stufe AA

Navigation, die sich auf mehreren Seiten wiederholt, erscheint jedes Mal in derselben relativen Reihenfolge
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.2.4 Konsistente Erkennung

Stufe AA

Komponenten, die über Seiten hinweg dasselbe tun, werden einheitlich gekennzeichnet
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.2.6 Konsistente Hilfe

Stufe A

Hilfe, die auf mehreren Seiten angeboten wird, steht jedes Mal an derselben relativen Stelle
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.3 Hilfestellung bei der Eingabe

3.3.1 Fehlererkennung

Stufe A

Ein Eingabefehler, den die Seite erkennt, wird in Text angezeigt, der sagt, welches Feld falsch ist und was falsch ist
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Eine Tastatur, Ein Screenreader
  1. Suchen Sie jedes Formular auf der Seite und senden Sie es leer ab, dann mit falschen Werten: eine fehlerhafte E-Mail-Adresse, Buchstaben in einem Zahlenfeld, ein Datum in der Vergangenheit.
  2. Prüfen Sie, ob jeder Fehler, den die Seite erkennt, in Text angezeigt wird, nicht nur durch Farbe oder ein Symbol, neben dem Feld oder in einer Liste oben.
  3. Prüfen Sie, ob der Text sagt, welches Feld falsch ist und was daran falsch ist.
  4. Die eigenen Validierungsmeldungen des Browsers zählen als Text, aber ihr Wortlaut und wie lange sie auf dem Bildschirm bleiben, unterscheiden sich zwischen Browsern. Prüfen Sie sie in jedem Browser, mit dem Sie testen.
  5. Prüfen Sie mit einem Screenreader, ob der Fehler angesagt wird oder leicht erreichbar ist und ob jedes falsche Feld als ungültig markiert ist.
Bestanden, wenn
Jeder Eingabefehler, den die Seite erkennt, wird in Text angezeigt, der das Feld und das Problem nennt.
Nicht bestanden, wenn
Ein Eingabefehler wird nur durch Farbe oder ein Symbol, gar nicht oder ohne Angabe des falschen Feldes angezeigt; das verstößt gegen WCAG 3.3.1.

Regeln, die es prüfen: invalid-field-error-message

Dieser Prüfschritt prüft auch:

  • Ein mit aria-invalid als ungültig markiertes Feld hat eine angezeigte Fehlermeldung in Textform, die mit ihm verknüpft ist

3.3.2 Beschriftungen (Labels) oder Anweisungen

Stufe A

Felder, die eine Eingabe verlangen, haben eine sichtbare Beschriftung und, wo die Eingabe es erfordert, Anweisungen
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Suchen Sie jedes Feld und jedes Bedienelement auf der Seite, das eine Eingabe verlangt.
  2. Prüfen Sie, ob jedes eine Beschriftung hat, die Sie sehen, ohne mit der Maus darüberzufahren oder etwas einzugeben: nicht nur einen Platzhalter, der beim Tippen verschwindet, oder einen title, der beim Überfahren angezeigt wird.
  3. Muss die Eingabe Regeln folgen, etwa einem Datumsformat, den Anforderungen an ein Passwort oder der Angabe, welche Felder Pflichtfelder sind, prüfen Sie, ob die Seite dies sagt, bevor Nutzende das Formular absenden.
  4. Dieses Kriterium verlangt nur, dass Beschriftungen und Anweisungen angezeigt werden. Ob eine Beschriftung im Markup mit ihrem Feld verknüpft ist, wird unter 1.3.1 und 4.1.2 geprüft.
Bestanden, wenn
Jedes Feld hat eine sichtbare Beschriftung, und die Seite gibt die Anweisungen, die die Eingabe erfordert, bevor sie abgesendet wird.
Nicht bestanden, wenn
Ein Feld hat keine sichtbare Beschriftung, nur einen Platzhalter oder einen title beim Überfahren, oder Eingaberegeln werden erst nach einem Fehler genannt; das verstößt gegen WCAG 3.3.2.

Regeln, die es prüfen: form-control-programmatic-label-present, form-control-single-label, form-control-programmatic-label-quality

Dieser Prüfschritt prüft auch:

  • Formularelemente bieten Beschriftungen oder Anweisungen (label/aria-label/aria-labelledby/title/placeholder)
  • Formularelemente sind mit höchstens einem <label> verknüpft
  • Formularelemente haben eine Beschriftung, die allen Nutzenden angezeigt wird, nicht nur einen title oder placeholder

3.3.3 Fehlerempfehlung

Stufe AA

Weiß die Seite, wie sich ein Eingabefehler beheben lässt, sagt sie es
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten)

Stufe AA

Übermittlungen mit rechtlicher oder finanzieller Wirkung oder solche, die gespeicherte Daten ändern, lassen sich rückgängig machen, werden geprüft oder lassen sich überprüfen und bestätigen
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.3.7 Redundante Eingabe

Stufe A

Informationen, die Nutzende in einem Prozess bereits angegeben haben, werden automatisch ausgefüllt oder zur Auswahl angeboten, nicht erneut abgefragt
  • Nur ein Mensch kann es prüfen

Dafür gibt es noch keinen Prüfschritt.

3.3.8 Barrierefreie Authentifizierung (Minimum)

Stufe AA

Die Anmeldung verlangt nicht, sich etwas zu merken, etwas abzuschreiben oder etwas zu lösen, es sei denn, es wird ein Weg daran vorbei angeboten
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: nur ein Browser
  1. Gehen Sie mit einem Testkonto jeden Weg durch, auf dem Sie sich auf der Website anmelden oder Ihre Identität bestätigen können.
  2. Notieren Sie jeden Schritt, der verlangt, dass Sie sich etwas merken (ein Passwort), etwas abschreiben (einen Code von einem anderen Gerät) oder etwas lösen (ein Puzzle, eine Rechnung, die Auswahl von Bildern).
  3. Prüfen Sie bei einem Passwort oder Code, ob Sie ihn einfügen können und ob ein Passwortmanager ihn ausfüllen kann, sodass er weder gemerkt noch erneut eingetippt werden muss.
  4. Prüfen Sie, ob ein Passwortmanager die Felder tatsächlich ausfüllt: Die Felder für Benutzername und Passwort brauchen autocomplete="username" und autocomplete="current-password" (oder new-password), und ein Feld für einen Einmalcode funktioniert am besten mit autocomplete="one-time-code".
  5. Ist ein Code in ein Kästchen pro Ziffer aufgeteilt, fügen Sie den ganzen Code in das erste Kästchen ein und prüfen Sie, ob er alle füllt. Kästchen, die das Einfügen blockieren oder jeweils nur ein Zeichen annehmen, bestehen nicht.
  6. Prüfen Sie bei anderen Tests, ob eine andere Methode angeboten wird oder ob der Test nur verlangt, Objekte oder etwas, das Sie der Website gegeben haben, wiederzuerkennen.
  7. Zählen Sie ein CAPTCHA, das bei der Anmeldung angezeigt wird, als Teil der Anmeldung. Andere Methoden, die keinen kognitiven Test erfordern, etwa ein Passkey, ein per E-Mail gesendeter Anmeldelink oder die Anmeldung über einen Drittanbieter, sind gültige Alternativen.
Bestanden, wenn
Jeder Anmeldeschritt, der verlangt, sich etwas zu merken, etwas abzuschreiben oder etwas zu lösen, erlaubt das Einfügen und Passwortmanager oder bietet einen anderen Weg an oder verlangt nur, Objekte oder eigene Inhalte wiederzuerkennen.
Nicht bestanden, wenn
Die Anmeldung verlangt, sich etwas zu merken, etwas abzuschreiben oder etwas zu lösen, ohne Weg daran vorbei, etwa ein Codefeld, das das Einfügen blockiert; das verstößt gegen WCAG 3.3.8.

Regeln, die es prüfen: password-paste-enabled

Dieser Prüfschritt prüft auch:

  • Ein Feld für ein Passwort oder einen Einmalcode unterbindet das Einfügen nicht, sodass ein Passwortmanager oder die Zwischenablage es weiterhin füllen kann

4 Robust

4.1 Kompatibel

4.1.2 Name, Rolle, Wert

Stufe A

Jeder Link, jedes Bedienelement, jeder Frame und jeder Dialog hat einen Namen, der sagt, wofür er dient
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Gehen Sie jeden Link, jede Schaltfläche, jedes Feld, jeden Frame und jedes benutzerdefinierte Bedienelement auf der Seite durch, mit Tab und innerhalb von Widgets mit den Pfeiltasten.
  2. Lesen Sie bei jedem den Eintrag „Name“ im Bereich „Barrierefreiheit“ der Entwicklertools oder hören Sie, was ein Screenreader ansagt.
  3. Prüfen Sie die Namen mit zwei Kombinationen aus Browser und Screenreader. Namen, die aus aria-labelledby, aus einem label, das das Bedienelement umschließt, oder aus CSS-content gebildet werden, können sich zwischen ihnen unterscheiden.
  4. Prüfen Sie, ob jedes einen Namen hat, der sagt, wofür es dient, einschließlich Schaltflächen, die nur aus einem Symbol bestehen, Frames („Videoplayer“, „Karte“) und Dialoge.
  5. Prüfen Sie, ob Frames mit demselben Namen dasselbe zeigen und ob Namen, die nur für Braille angegeben sind, eine gesprochene Entsprechung haben.
Bestanden, wenn
Jeder Link, jedes Bedienelement, jeder Frame und jeder Dialog hat einen Namen, der sagt, wofür er dient.
Nicht bestanden, wenn
Ein Link, ein Bedienelement, ein Frame oder ein Dialog hat keinen Namen oder einen, der nicht sagt, wofür er dient, sodass assistive Technologien nur seine Rolle ansagen; das verstößt gegen WCAG 4.1.2.

Regeln, die es prüfen: form-control-programmatic-label-present, link-name-present, button-name-present, input-image-alt-present, binary-control-name-present, combobox-name-present, dialog-name-present, menuitem-name-present, tab-name-present, slider-name-present, textbox-name-present, searchbox-name-present, spinbutton-name-present, listbox-name-present, option-name-present, treeitem-name-present, aria-role-name-present, iframe-name-present, identical-iframes-same-purpose, iframe-title-unique, summary-name-present, tooltip-name-present, aria-braille-equivalent

Dieser Prüfschritt prüft auch:

  • Formularelemente stellen einen zugänglichen Namen bereit (label/aria-label/aria-labelledby/title/placeholder)
  • Links stellen einen zugänglichen Namen bereit (Textinhalt / aria-label / aria-labelledby / title)
  • Schaltflächen stellen einen zugänglichen Namen bereit (Textinhalt / aria-label / aria-labelledby / title / value)
  • Grafische Schaltflächen (<input type="image">) stellen einen zugänglichen Namen bereit (aria-labelledby / aria-label / alt / title)
  • Kontrollkästchen stellen einen zugänglichen Namen bereit (label / aria-label / aria-labelledby / title)
  • Optionsfelder stellen einen zugänglichen Namen bereit (label / aria-label / aria-labelledby / title)
  • Schalter stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Comboboxen stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Dialoge stellen einen zugänglichen Namen bereit (aria-labelledby / aria-label / title / Inhalt)
  • Menüeinträge stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Tabs stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Schieberegler stellen einen zugänglichen Namen bereit (label / aria-label / aria-labelledby / title / Inhalt)
  • Textfelder (role="textbox") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Suchfelder (role="searchbox") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Drehfelder (role="spinbutton") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Listenfelder (role="listbox") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Optionen (role="option") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Baumeinträge (role="treeitem") stellen einen zugänglichen Namen bereit (Inhalt / aria-label / aria-labelledby / title)
  • Ausgewählte ARIA-Widget- und Container-Rollen (scrollbar, toolbar, tablist, radiogroup, tree, grid, menu, menubar) stellen einen zugänglichen Namen bereit
  • <iframe>/<frame>-Elemente stellen einen zugänglichen Namen bereit (aria-label / aria-labelledby / title)
  • <iframe>/<frame>-Elemente mit demselben zugänglichen Namen betten dieselbe Ressource ein
  • <summary>-Elemente stellen einen zugänglichen Namen bereit
  • Elemente mit role="tooltip" stellen einen zugänglichen Namen bereit
  • aria-braillelabel/aria-brailleroledescription haben eine Entsprechung außerhalb von Braille
Die Rolle jedes Bedienelements sagt, was es tut, und Bedienelemente sind nicht ineinander verschachtelt
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader
  1. Notieren Sie bei jedem Bedienelement auf der Seite, was es bei der Bedienung tut: eine Seite öffnen (ein Link), auf der Seite etwas auslösen (eine Schaltfläche), umschalten (ein Kontrollkästchen oder Schalter), eine Liste öffnen (ein Menü oder eine Combobox).
  2. Lesen Sie seinen Eintrag „Rolle“ im Bereich „Barrierefreiheit“ der Entwicklertools oder hören Sie mit einem Screenreader hin und prüfen Sie, ob die Rolle dazu passt, was es tut.
  3. Achten Sie auf benutzerdefinierte Bedienelemente aus divs und spans, auf Links, die als Schaltflächen verwendet werden, und auf Schaltflächen, die als Links verwendet werden.
  4. Prüfen Sie, ob kein Bedienelement ein anderes enthält, etwa eine Schaltfläche in einem Link, und ob Bedienelemente mit präsentativen Kindelementen, etwa ein Tab oder eine Schaltfläche, nichts Fokussierbares enthalten.
Bestanden, wenn
Die Rolle jedes Bedienelements sagt, was es tut, und kein Bedienelement ist in ein anderes verschachtelt.
Nicht bestanden, wenn
Ein Bedienelement hat keine Rolle, eine falsche (ein anklickbares div ohne Rolle, ein Link, der als Schaltfläche funktioniert) oder enthält ein anderes Bedienelement; das verstößt gegen WCAG 4.1.2.

Regeln, die es prüfen: aria-roles-valid, aria-deprecated-role, nested-interactive-controls-absent, presentational-children-focusable-absent

Dieser Prüfschritt prüft auch:

  • Ein explizites role-Attribut ergibt eine echte, nicht abstrakte ARIA-Rolle
  • Ein explizites role-Attribut verwendet keine veraltete ARIA-Rolle
  • Interaktive Bedienelemente enthalten keine anderen interaktiven Bedienelemente
  • Rollen mit präsentativen Kindelementen enthalten keine Inhalte in der sequenziellen Fokusnavigation
Zustand und Wert jedes Bedienelements werden bereitgestellt und ändern sich mit dem, was auf dem Bildschirm zu sehen ist
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers, Ein Screenreader, Eine Tastatur
  1. Suchen Sie die Bedienelemente, die einen Zustand oder Wert haben: Kontrollkästchen, Schalter, Optionsfelder, aufklappbare Abschnitte und Menüs, Tabs, Schieberegler, ausgewählte Einträge, gedrückte Schaltflächen.
  2. Lesen Sie Zustand und Wert jedes davon im Bereich „Barrierefreiheit“ der Entwicklertools oder hören Sie mit einem Screenreader hin: checked, expanded, selected, pressed, der aktuelle Eintrag (aria-current) und der aktuelle Wert eines Schiebereglers oder Drehfelds.
  3. Ändern Sie jeden mit der Tastatur und prüfen Sie, ob sich der vorgelesene Zustand oder Wert mit dem ändert, was Sie sehen.
  4. Prüfen Sie bei einem aufklappbaren Bedienelement, ob es nur „erweitert“ angibt, solange das, was es öffnet, angezeigt wird.
Bestanden, wenn
Zustand und Wert jedes Bedienelements werden bereitgestellt und ändern sich mit dem, was auf dem Bildschirm zu sehen ist.
Nicht bestanden, wenn
Zustand oder Wert eines Bedienelements werden nicht bereitgestellt oder ändern sich nicht, wenn sie sich auf dem Bildschirm ändern, etwa ein benutzerdefiniertes Kontrollkästchen, das immer als nicht aktiviert vorgelesen wird; das verstößt gegen WCAG 4.1.2.

Regeln, die es prüfen: aria-required-attr, aria-conditional-attr, aria-checked-state-mismatch, aria-expanded-state-mismatch

Dieser Prüfschritt prüft auch:

  • Rollen mit einem eindeutig erforderlichen Zustand oder einer eindeutig erforderlichen Eigenschaft haben diese (z. B. hat role="checkbox" aria-checked)
  • aria-errormessage wird nur verwendet, wenn aria-invalid nicht false oder abwesend ist
  • aria-checked an einem nativen Kontrollkästchen oder Optionsfeld entspricht seinem tatsächlichen checked- oder indeterminate-Zustand (nur Indiz: statisches Markup kann eine spätere Hydration per JS nicht ausschließen)
  • aria-expanded entspricht dem, ob der in aria-controls genannte Inhalt angezeigt wird (nur Indiz: statisches Markup kann einen Übergang oder ein noch nicht ausgeführtes Skript erfassen)
ARIA-Attribute sind echt, gültig und dort erlaubt, wo sie stehen, und nichts Fokussierbares ist vor assistiven Technologien verborgen
  • Regeln entscheiden es zum Teil
  • Hilfsmittel: Die Entwicklertools des Browsers
  1. Durchsuchen Sie im Bereich „Elemente“ der Entwicklertools das Markup nach aria- und role= und sehen Sie sich jede Verwendung an.
  2. Prüfen Sie, ob jedes aria-*-Attribut ein echtes ist, einen gültigen Wert hat und für die Rolle seines Elements erlaubt ist.
  3. Prüfen Sie, ob ids, auf die aria-labelledby, aria-describedby, aria-controls und Ähnliche verweisen, jeweils genau einmal existieren.
  4. Prüfen Sie, ob nichts, was den Fokus erhält, in einem Element mit aria-hidden="true" liegt und ob <body> nicht verborgen ist.
Bestanden, wenn
ARIA-Attribute sind echt, gültig und dort erlaubt, wo sie stehen, ihre ids sind eindeutig, und nichts Fokussierbares ist verborgen.
Nicht bestanden, wenn
Ein ARIA-Attribut ist falsch geschrieben, hat einen ungültigen Wert oder ist für seine Rolle nicht erlaubt, eine id, auf die es verweist, fehlt oder ist mehrfach vorhanden, oder etwas Fokussierbares ist vor assistiven Technologien verborgen; das verstößt gegen WCAG 4.1.2.

Regeln, die es prüfen: aria-hidden-focus, aria-valid-attr, aria-valid-attr-value, aria-allowed-attr, aria-prohibited-attr, aria-hidden-body, duplicate-id-aria

Dieser Prüfschritt prüft auch:

  • Ein aria-hidden-Teilbaum enthält fokussierbare Inhalte
  • Jeder vorhandene aria-*-Attributname ist ein echtes, definiertes ARIA-Attribut
  • Jedes erkannte aria-*-Attribut hat einen Wert, der seinem deklarierten Typ entspricht
  • Vorhandene aria-*-Attribute sind für die explizite Rolle des Elements erlaubt
  • ARIA-Attribute zur Benennung werden nicht an Rollen verwendet, die sie verbieten
  • Das <body> des Dokuments hat kein aria-hidden="true"
  • IDs, auf die ARIA-Attribute mit ID-Referenzen verweisen, sind im Dokument eindeutig

4.1.3 Statusmeldungen

Stufe AA

Statusmeldungen werden von assistiven Technologien angesagt, ohne den Fokus zu erhalten
  • Nur ein Mensch kann es prüfen
  • Hilfsmittel: Ein Screenreader
  1. Suchen Sie die Meldungen, die die Seite anzeigt, ohne den Fokus zu bewegen: „In den Warenkorb gelegt“, die Anzahl der Suchergebnisse, „Gespeichert“, Fortschritt, nach dem Absenden aufgelistete Formularfehler.
  2. Schalten Sie einen Screenreader ein und lösen Sie jede Meldung durch die Aktion aus, die sie anzeigt.
  3. Prüfen Sie, ob der Screenreader die Meldung ansagt, ohne dass der Fokus zu ihr wechselt.
  4. Wiederholen Sie dies mit einer zweiten Kombination aus Browser und Screenreader. Live-Regionen gehören zu den am wenigsten einheitlichen Bereichen der Screenreader-Unterstützung.
  5. Sagt er nichts, prüfen Sie in den Entwicklertools, ob die Meldung in einem Element mit role="status", role="alert" oder aria-live steht und ob das Element nicht verborgen ist. Eine Region mit role="status" oder aria-live muss bereits leer auf der Seite vorhanden sein, bevor die Meldung in sie eingefügt wird. Ein Element mit role="alert" wird meist auch dann angesagt, wenn es zusammen mit seiner Meldung hinzugefügt wird.
  6. Lassen Sie Meldungen weg, die den Fokus erhalten oder mit einer neuen Seite erscheinen: Das sind keine Statusmeldungen, und sie werden unter anderen Kriterien geprüft.
Bestanden, wenn
Jede Statusmeldung wird von einem Screenreader angesagt, ohne dass der Fokus zu ihr wechselt.
Nicht bestanden, wenn
Eine Statusmeldung erscheint auf dem Bildschirm, aber ein Screenreader sagt sie nicht an; das verstößt gegen WCAG 4.1.3.

Regeln, die es prüfen: live-region-announcements

Dieser Prüfschritt prüft auch:

  • Eine Live-Region ist nicht durch aria-hidden oder inert vor assistiven Technologien verborgen und bleibt nicht dauerhaft im Zustand busy (nur Indiz: ob die Seite sie für Statusmeldungen nutzt, muss ein Mensch beurteilen)
  • Eine Live-Region erhält ihre Statusmeldung erst, nachdem sie im Barrierefreiheitsbaum ist, und wird nicht zusammen mit ihr hinzugefügt oder angezeigt (nur Indiz: erfordert den Live-Region-Hook, und Screenreader verhalten sich unterschiedlich)