WCAG 2.2: manuelle Checkliste

Prüfungen: 50 · Anforderungen: 30

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.

Ihre Ergebnisse

Geprüft: 0 von 50 · Bestanden: 0 · Nicht bestanden: 0 · Nicht anwendbar: 0

Ihre Ergebnisse werden nur in diesem Browser gespeichert, bis Sie sie löschen. Laden Sie sie herunter, um sie aufzubewahren oder weiterzugeben.

1 Wahrnehmbar

1.1 Textalternativen

Nicht-Text-Inhalte, die etwas vermitteln, haben eine Textalternative

Für: 1.1.1

  • 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 und Facetten

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

Er prüft auch: img-alt-attr-present, role-img-text-alternative-present, canvas-text-alternative-present, embed-text-alternative-present, svg-text-alt-present, svg-text-alternative-present, svg-image-text-alt-present, object-text-alternative-present, video-poster-text-alt-present, meter-name-present, progressbar-name-present

Ergebnis: Nicht-Text-Inhalte, die etwas vermitteln, haben eine Textalternative

Bilder und Symbole, die als Bedienelemente dienen, sind nach ihrer Funktion benannt

Für: 1.1.1

  • 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 und Facetten

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

Er prüft auch: input-image-alt-attr-present, area-alt-attr-present

Ergebnis: Bilder und Symbole, die als Bedienelemente dienen, sind nach ihrer Funktion benannt

Dekorative Bilder sind vor assistiven Technologien verborgen, und nur diese

Für: 1.1.1

  • 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.
Ergebnis: Dekorative Bilder sind vor assistiven Technologien verborgen, und nur diese

Jede Textalternative gibt wieder, was ihr Bild vermittelt

Für: 1.1.1

  • 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 und Facetten

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

Er prüft auch: text-alt-quality-review, alt-suspicious-patterns

Ergebnis: Jede Textalternative gibt wieder, was ihr Bild vermittelt

Ein CAPTCHA sagt, wofür es dient, und bietet eine andere Form an, die einen anderen Sinn nutzt

Für: 1.1.1

  • 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.
Ergebnis: Ein CAPTCHA sagt, wofür es dient, und bietet eine andere Form an, die einen anderen Sinn nutzt

1.2 Zeitbasierte Medien

Aufgezeichnete reine Audio- und Videoinhalte haben ein Transkript oder eine gleichwertige Alternative

Für: 1.2.1

  • 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 und Facetten

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

Ergebnis: Aufgezeichnete reine Audio- und Videoinhalte haben ein Transkript oder eine gleichwertige Alternative

Aufgezeichnete Videos mit Ton haben Untertitel

Für: 1.2.2

  • 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 und Facetten

Regeln, die es prüfen: video-caption

Ergebnis: Aufgezeichnete Videos mit Ton haben Untertitel

Untertitel geben alle Dialoge, die sprechende Person und die wichtigen Geräusche wieder, synchron zum Video

Für: 1.2.2

  • 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).
Ergebnis: Untertitel geben alle Dialoge, die sprechende Person und die wichtigen Geräusche wieder, synchron zum Video

1.3 Anpassbar

Text, der wie eine Überschrift aussieht, ist als Überschrift ausgezeichnet, mit einer Ebene, die zur Gliederung der Seite passt

Für: 1.3.1

  • 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 und Facetten

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

Er prüft auch: p-as-heading-evidence

Ergebnis: Text, der wie eine Überschrift aussieht, ist als Überschrift ausgezeichnet, mit einer Ebene, die zur Gliederung der Seite passt

Inhalte, die als Liste dargestellt werden, sind als Liste ausgezeichnet

Für: 1.3.1

  • 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 und Facetten

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

Er prüft auch: list-children-valid, listitem-parent-valid, definition-list-children-valid, dlitem-parent-valid

Ergebnis: Inhalte, die als Liste dargestellt werden, sind als Liste ausgezeichnet

Datentabellen zeichnen ihre Kopfzellen und ihre Tabellenbeschriftung aus, und reine Layouttabellen haben kein Kopfzellen-Markup

Für: 1.3.1

  • 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 und Facetten

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

Er prüft auch: table-headers-attr-valid, table-th-has-data-cells, table-fake-caption-evidence, td-has-header

Ergebnis: Datentabellen zeichnen ihre Kopfzellen und ihre Tabellenbeschriftung aus, und reine Layouttabellen haben kein Kopfzellen-Markup

Formularfelder sind mit ihren sichtbaren Beschriftungen verknüpft, Gruppen von Feldern mit dem Text, der die Gruppe benennt

Für: 1.3.1

  • 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 und Facetten

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

Er prüft auch: form-control-programmatic-label-present, form-control-label-quality-review

Ergebnis: Formularfelder sind mit ihren sichtbaren Beschriftungen verknüpft, Gruppen von Feldern mit dem Text, der die Gruppe benennt

ARIA-Rollen und -Beziehungen ergeben dieselbe Struktur, die die Seite zeigt

Für: 1.3.1

  • 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 und Facetten

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

Er prüft auch: aria-hidden-body-absent, aria-role-required-owned-children, aria-role-owned-children-allowed, aria-role-required-context-parent, aria-role-valid, aria-owns-valid

Ergebnis: ARIA-Rollen und -Beziehungen ergeben dieselbe Struktur, die die Seite zeigt

Bedeutung, die durch Gestaltung oder Layout vermittelt wird, etwa Fettdruck, Farbe, Position oder ein Sternchen, steht auch im Markup oder im Text

Für: 1.3.1

  • 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.
Ergebnis: Bedeutung, die durch Gestaltung oder Layout vermittelt wird, etwa Fettdruck, Farbe, Position oder ein Sternchen, steht auch im Markup oder im Text

Die Seite funktioniert im Hoch- und im Querformat, sofern nicht eine Ausrichtung wesentlich ist

Für: 1.3.4

  • 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 und Facetten

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

Er prüft auch: css-orientation-lock

Ergebnis: Die Seite funktioniert im Hoch- und im Querformat, sofern nicht eine Ausrichtung wesentlich ist

Felder, die Informationen über die Nutzenden abfragen, benennen ihren Zweck mit dem richtigen autocomplete-Wert

Für: 1.3.5

  • 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 und Facetten

Regeln, die es prüfen: autocomplete-valid

Er prüft auch: autocomplete-valid

Ergebnis: Felder, die Informationen über die Nutzenden abfragen, benennen ihren Zweck mit dem richtigen autocomplete-Wert

1.4 Unterscheidbar

Farbe ist nicht das einzige Mittel, um Informationen zu zeigen, zu einer Auswahl aufzufordern oder ein Element hervorzuheben

Für: 1.4.1

  • 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 und Facetten

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

Er prüft auch: link-in-text-block

Ergebnis: Farbe ist nicht das einzige Mittel, um Informationen zu zeigen, zu einer Auswahl aufzufordern oder ein Element hervorzuheben

Ton, der von selbst länger als 3 Sekunden abgespielt wird, lässt sich pausieren, stoppen oder leiser stellen

Für: 1.4.2

  • 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 und Facetten

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

Ergebnis: Ton, der von selbst länger als 3 Sekunden abgespielt wird, lässt sich pausieren, stoppen oder leiser stellen

Text hat einen Kontrast von mindestens 4,5:1 zu seinem Hintergrund, bei großem Text 3:1

Für: 1.4.3

  • 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 und Facetten

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

Er prüft auch: contrast-computability-143

Ergebnis: Text hat einen Kontrast von mindestens 4,5:1 zu seinem Hintergrund, bei großem Text 3:1

Text lässt sich ohne Verlust von Inhalt oder Funktion auf 200 % vergrößern

Für: 1.4.4

  • 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 und Facetten

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

Er prüft auch: meta-viewport-zoom-enabled

Ergebnis: Text lässt sich ohne Verlust von Inhalt oder Funktion auf 200 % vergrößern

Text wird als Text gezeigt, nicht in einem Bild, es sei denn, sein Aussehen ist wesentlich, wie bei einem Logo

Für: 1.4.5

  • 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 und Facetten

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

Er prüft auch: image-of-text-evidence

Ergebnis: Text wird als Text gezeigt, nicht in einem Bild, es sei denn, sein Aussehen ist wesentlich, wie bei einem Logo

In einem style-Attribut erzwungene Abstände verhindern nicht, dass Text die Abstände der Nutzenden übernimmt

Für: 1.4.12

  • 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 und Facetten

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

Ergebnis: In einem style-Attribut erzwungene Abstände verhindern nicht, dass Text die Abstände der Nutzenden übernimmt

Mit den Abständen aus 1.4.12 wird kein Text abgeschnitten oder überlappt (im Browser gemessen)

Für: 1.4.12

  • 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 und Facetten

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

Ergebnis: Mit den Abständen aus 1.4.12 wird kein Text abgeschnitten oder überlappt (im Browser gemessen)

Mit den Abständen aus 1.4.12 funktionieren Bedienelemente, Menüs und Formulare weiter und zeigen ihren ganzen Text

Für: 1.4.12

  • 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.
Ergebnis: Mit den Abständen aus 1.4.12 funktionieren Bedienelemente, Menüs und Formulare weiter und zeigen ihren ganzen Text

Mit den Abständen aus 1.4.12 behalten Inhalte, die erst nach einer Interaktion erscheinen (Menüs, Dialoge, Tabs, Meldungen), ihren ganzen Text

Für: 1.4.12

  • 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.
Ergebnis: Mit den Abständen aus 1.4.12 behalten Inhalte, die erst nach einer Interaktion erscheinen (Menüs, Dialoge, Tabs, Meldungen), ihren ganzen Text

2 Bedienbar

2.1 Per Tastatur zugänglich

Alle Funktionen lassen sich allein mit der Tastatur bedienen

Für: 2.1.1

  • 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 und Facetten

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

Er prüft auch: iframe-tabindex-negative-content-not-focusable, server-side-image-map-absent, scrollable-region-focusable-evidence, mouse-only-event-handlers-evidence, click-handler-keyboard-operable, widget-keyboard-focusable-evidence, focus-not-removed-by-script-evidence

Ergebnis: Alle Funktionen lassen sich allein mit der Tastatur bedienen

2.2 Ausreichend Zeit

Jede Zeitbegrenzung lässt sich ausschalten, anpassen oder verlängern, sofern sie nicht in Echtzeit abläuft, wesentlich ist oder 20 Stunden überschreitet

Für: 2.2.1

  • 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 und Facetten

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

Er prüft auch: meta-refresh-timing-absent

Ergebnis: Jede Zeitbegrenzung lässt sich ausschalten, anpassen oder verlängern, sofern sie nicht in Echtzeit abläuft, wesentlich ist oder 20 Stunden überschreitet

Animationen, die von selbst starten und länger als fünf Sekunden dauern, lassen sich pausieren, beenden oder ausblenden

Für: 2.2.2

  • 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 und Facetten

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

Er prüft auch: deprecated-non-stoppable-elements-absent

Ergebnis: Animationen, die von selbst starten und länger als fünf Sekunden dauern, lassen sich pausieren, beenden oder ausblenden

Inhalte, die sich von selbst aktualisieren, lassen sich pausieren, beenden, ausblenden oder seltener aktualisieren

Für: 2.2.2

  • 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.
Ergebnis: Inhalte, die sich von selbst aktualisieren, lassen sich pausieren, beenden, ausblenden oder seltener aktualisieren

2.3 Anfälle und physische Reaktionen

2.4 Navigierbar

Blöcke, die sich auf mehreren Seiten wiederholen, lassen sich überspringen

Für: 2.4.1

  • 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 und Facetten

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

Ergebnis: Blöcke, die sich auf mehreren Seiten wiederholen, lassen sich überspringen

Die Seite hat einen Titel, der sagt, worum es geht oder wofür sie dient, und sie von den anderen Seiten der Website unterscheidet

Für: 2.4.2

  • 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 und Facetten

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

Er prüft auch: page-title-present, page-title-patterns

Ergebnis: Die Seite hat einen Titel, der sagt, worum es geht oder wofür sie dient, und sie von den anderen Seiten der Website unterscheidet

Das Bewegen des Fokus mit Tab und Umschalttaste+Tab folgt einer Reihenfolge, die die Bedeutung der Seite erhält und ihre Bedienung ermöglicht

Für: 2.4.3

  • 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.
Ergebnis: Das Bewegen des Fokus mit Tab und Umschalttaste+Tab folgt einer Reihenfolge, die die Bedeutung der Seite erhält und ihre Bedienung ermöglicht

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

Für: 2.4.3

  • 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.
Ergebnis: 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

Der Fokus hält nicht an Inhalten, die geschlossen, verborgen oder außerhalb des Bildschirms sind

Für: 2.4.3

  • 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.
Ergebnis: Der Fokus hält nicht an Inhalten, die geschlossen, verborgen oder außerhalb des Bildschirms sind

Überschriften beschreiben die Inhalte, die ihnen folgen

Für: 2.4.6

  • 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 und Facetten

Regeln, die es prüfen: heading-quality

Ergebnis: Überschriften beschreiben die Inhalte, die ihnen folgen

Beschriftungen beschreiben ihre Felder, und Felder mit derselben Beschriftung sind unterscheidbar

Für: 2.4.6

  • 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 und Facetten

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

Ergebnis: Beschriftungen beschreiben ihre Felder, und Felder mit derselben Beschriftung sind unterscheidbar

Jedes Element, das den Tastaturfokus erhält, zeigt an, dass es ihn hat

Für: 2.4.7

  • 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 und Facetten

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

Er prüft auch: css-hidden-focusable, focus-indicator-not-suppressed, focus-not-removed-by-script-evidence

Ergebnis: Jedes Element, das den Tastaturfokus erhält, zeigt an, dass es ihn hat

2.5 Eingabemodalitäten

Der Name eines Bedienelements enthält den Text seiner sichtbaren Beschriftung

Für: 2.5.3

  • 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 und Facetten

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

Ergebnis: Der Name eines Bedienelements enthält den Text seiner sichtbaren Beschriftung

Ziele sind mindestens 24 mal 24 CSS-Pixel groß oder weit genug voneinander entfernt

Für: 2.5.8

  • 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 und Facetten

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

Ergebnis: Ziele sind mindestens 24 mal 24 CSS-Pixel groß oder weit genug voneinander entfernt

3 Verständlich

3.1 Lesbar

Die Hauptsprache der Seite ist im Markup angegeben und ist die richtige

Für: 3.1.1

  • 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 und Facetten

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

Er prüft auch: html-lang-attr-present, html-xml-lang-mismatch

Ergebnis: Die Hauptsprache der Seite ist im Markup angegeben und ist die richtige

Passagen und Ausdrücke in einer anderen Sprache als der der Seite sind mit ihrer eigenen Sprache ausgezeichnet

Für: 3.1.2

  • 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 und Facetten

Regeln, die es prüfen: valid-lang

Er prüft auch: element-lang-valid

Ergebnis: Passagen und Ausdrücke in einer anderen Sprache als der der Seite sind mit ihrer eigenen Sprache ausgezeichnet

3.2 Vorhersehbar

3.3 Hilfestellung bei der Eingabe

Ein Eingabefehler, den die Seite erkennt, wird in Text angezeigt, der sagt, welches Feld falsch ist und was falsch ist

Für: 3.3.1

  • 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 und Facetten

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

Er prüft auch: invalid-field-error-message

Ergebnis: Ein Eingabefehler, den die Seite erkennt, wird in Text angezeigt, der sagt, welches Feld falsch ist und was falsch ist

Felder, die eine Eingabe verlangen, haben eine sichtbare Beschriftung und, wo die Eingabe es erfordert, Anweisungen

Für: 3.3.2

  • 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 und Facetten

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

Er prüft auch: form-control-labels-or-instructions-present, form-control-single-label, form-control-visible-label-quality

Ergebnis: Felder, die eine Eingabe verlangen, haben eine sichtbare Beschriftung und, wo die Eingabe es erfordert, Anweisungen

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

Für: 3.3.8

  • 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 und Facetten

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

Er prüft auch: authentication-paste-not-blocked

Ergebnis: 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

4 Robust

4.1 Kompatibel

Jeder Link, jedes Bedienelement, jeder Frame und jeder Dialog hat einen Namen, der sagt, wofür er dient

Für: 4.1.2

  • 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 und Facetten

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

Er prüft auch: form-control-name-present, link-name-present, button-name-present, input-image-name-present, checkbox-name-present, radio-name-present, switch-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, summary-name-present, tooltip-name-present, aria-braille-equivalent

Ergebnis: Jeder Link, jedes Bedienelement, jeder Frame und jeder Dialog hat einen Namen, der sagt, wofür er dient

Die Rolle jedes Bedienelements sagt, was es tut, und Bedienelemente sind nicht ineinander verschachtelt

Für: 4.1.2

  • 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 und Facetten

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

Er prüft auch: aria-role-valid, aria-role-not-deprecated, nested-interactive-controls-absent, presentational-children-focusable-absent

Ergebnis: Die Rolle jedes Bedienelements sagt, was es tut, und Bedienelemente sind nicht ineinander verschachtelt

Zustand und Wert jedes Bedienelements werden bereitgestellt und ändern sich mit dem, was auf dem Bildschirm zu sehen ist

Für: 4.1.2

  • 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 und Facetten

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

Er prüft auch: aria-attr-required-for-role, aria-conditional-attr, aria-checked-state-mismatch, aria-expanded-state-mismatch

Ergebnis: Zustand und Wert jedes Bedienelements werden bereitgestellt und ändern sich mit dem, was auf dem Bildschirm zu sehen ist

ARIA-Attribute sind echt, gültig und dort erlaubt, wo sie stehen, und nichts Fokussierbares ist vor assistiven Technologien verborgen

Für: 4.1.2

  • 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 und Facetten

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

Er prüft auch: aria-hidden-focusable, aria-attr-name-valid, aria-attr-value-valid, aria-attr-allowed-for-role, aria-attr-not-prohibited, aria-hidden-body-absent, duplicate-id-aria

Ergebnis: ARIA-Attribute sind echt, gültig und dort erlaubt, wo sie stehen, und nichts Fokussierbares ist vor assistiven Technologien verborgen

Statusmeldungen werden von assistiven Technologien angesagt, ohne den Fokus zu erhalten

Für: 4.1.3

  • 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 und Facetten

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

Er prüft auch: live-region-reachable-evidence, live-region-changes-evidence

Ergebnis: Statusmeldungen werden von assistiven Technologien angesagt, ohne den Fokus zu erhalten