WCAG Prüfkriterien

Prüfschritte zur Tastaturzugänglichkeit:

1. Webseite im Firefox öffnen und den Fokus ins Browserfenster bringen (z. B. F6).
2. Mit der Tab-Taste systematisch alle Links, Schaltflächen, Formularelemente und sonstigen interaktiven Komponenten durchlaufen.
3. Prüfen, ob jedes Element per Tab erreichbar und mit Enter oder Leertaste (Space) aktivierbar ist.
4. Für Auswahllisten (select-Elemente): Mit Pfeiltasten und Enter navigieren. Falls per onchange reagiert wird: Mit Alt + Pfeil ↓ öffnen und dann mit Pfeil ↑/↓ Auswahl treffen.
5. Sichtbare Steuerelemente mit Mausinteraktionen (z. B. Hover-Effekte, Kontextmenüs) auf Tastatur-Äquivalente (Fokus-Trigger) prüfen.
6. Scrollbare Bereiche (Overlays, Scrollpanes) per Tab, Pfeil- oder Bild-Tasten ansteuern und durchlaufen.
7. Schritte 1–6 in Chrome wiederholen, um die browserübergreifende Tastaturzugänglichkeit zu verifizieren.

• Prüfung immer mit aktiviertem JavaScript durchführen, da Probleme meist durch Scripts verursacht werden.
• Browser-Fokus muss korrekt per Tastatur (F6) ins Fenster geholt werden - niemals durch Mausklick ins Fenster, da dies den Test verfälscht.
• Bei Dropdown-Listen ohne Submit-Button: Mit Alt + Pfeil nach unten öffnen, dann mit Pfeiltasten navigieren und mit Enter auswählen (verhindert ungewollte Auslösung der ersten Option).
• Tastaturbedienung muss nicht identisch zur Mausbedienung funktionieren - verschiedene Wege zum gleichen Ziel sind erlaubt.
• Wenn NVDA-Screenreader Elemente nicht aktivieren kann oder nur mit zusätzlicher Alt-Taste: deutet auf fehlerhafte ARIA-Implementierung hin.
• Unwichtige Browser-eigene Funktionen (wie "Fenster schließen") müssen nicht tastaturzugänglich gemacht werden.

1. Webseite in Firefox öffnen.
2. Fokus ins Browserfenster bringen (z. B. F6 oder Klick in den Seitenbereich, dann Tab).
3. Vorwärtsnavigation: Mit Tab-Taste alle interaktiven Elemente (Links, Buttons, Formulareingaben, Widgets, Modals, Karussells, Akkordeons etc.) durchlaufen. Prüfen, ob der Fokus jedes Element wieder verlassen kann.
4. Rückwärtsnavigation: Mit Shift + Tab die Navigation rückwärts prüfen – auch hier muss jedes Element verlassen werden können.
5. Spezialfälle testen: Modale/Lightboxen (Prüfen, ob der Fokus im Modal zirkuliert, aber über Esc oder Schließen-Button wieder in den Hauptinhalt zurückkehrt), Iframes / eingebettete Inhalte (Sicherstellen, dass der Fokus den eingebetteten Bereich wieder verlassen kann), Komplexe Widgets (Fokus darf nicht blockiert werden, auch bei dynamisch geladenen Elementen).
6. Abweichende Tastenkombinationen: Falls zum Verlassen eines Elements andere Tasten als Tab/Shift + Tab nötig sind (z. B. Esc), muss diese Info klar erkennbar sein.
7. Prüfung in mindestens einem weiteren Browser (z. B. Chrome) wiederholen.

• Test mit aktiviertem JavaScript durchführen, da Tastaturfallen meist durch Scripts entstehen.
• Besonders prüfen, ob Tastaturfallen den Zugang zu nachfolgenden Seitenbereichen blockieren.
• Falls Inhalte nach der Tastaturfalle nicht erreichbar sind, ist möglicherweise auch Prüfschritt 2.1.1 "Ohne Maus nutzbar" nicht erfüllt.

1. Umfassende Tastaturnavigation: Webseite vollständig laden, systematisch mit Tab (vorwärts) und Shift + Tab (rückwärts) alle interaktiven Elemente durchlaufen, auch eingeblendete Inhalte (Pop-ups, Modals, Akkordeons, Dropdowns, Tooltips) testen.
2. Vollständige Funktionsprüfung: Jede Funktion, die per Maus nutzbar ist (z. B. Formulare absenden, Medienplayer steuern, Bildergalerien bedienen), muss auch per Tastatur nutzbar sein. Steuerung darf nicht auf Maus-spezifische Gesten angewiesen sein.
3. Unabhängigkeit vom Timing: Testen, ob eine Funktion nur funktioniert, wenn Tasten in einem engen Zeitfenster gedrückt werden. Beispiel: Ein Slider, der nur reagiert, wenn die Pfeiltaste sehr schnell mehrmals gedrückt wird. Solche Timing-Anforderungen sind nicht zulässig.
4. Keine Ausnahmen: Es darf kein Element oder Funktion geben, die nicht tastaturbedienbar ist. Falls eine Interaktion spezielle Tasten erfordert (z. B. Esc zum Schließen eines Modals), muss dies klar und sichtbar kommuniziert werden.

Keine besonderen Hinweise für dieses Kriterium.

1. Test auf Einzeltasten-Shortcuts: Nacheinander alle Buchstaben-, Zahlen- und Symboltasten ohne Modifikatortaste drücken (z. B. a, b, 1, !). Vorgang wiederholen, während Shift gedrückt wird (z. B. A, B, @, %). Beobachten, ob dabei Aktionen ausgelöst werden (z. B. Ansicht ändern, Medien starten/stoppen, Inhalte ein-/ausblenden).
2. Prüfung der Steuerungsmöglichkeiten: Falls Einzeltasten-Kurzbefehle aktiv sind, prüfen, ob eine der folgenden Bedingungen erfüllt ist: Abschalten möglich (Es gibt eine Einstellung, um den Shortcut zu deaktivieren), Anpassung möglich (Shortcut kann so geändert werden, dass er Modifikatortasten erfordert, z. B. Strg + K statt nur k), Nur bei Fokus aktiv (Shortcut funktioniert nur, wenn die entsprechende Komponente, z. B. Medienplayer, den Fokus hat).
3. Fokus-Test (falls zutreffend): Fokus auf die zugehörige Komponente setzen, Shortcut auslösen → Funktion muss reagieren. Fokus entfernen, Shortcut auslösen → Funktion darf nicht reagieren.

• Ausnahme für kontextbezogene Shortcuts: Kurzbefehle sind erlaubt, wenn sie nur bei fokussierten Elementen aktiv sind (Beispiel: Buchstabe drücken für Navigation in Auswahlliste).
• Technische Prüfung: Im Code nach Event-Handlern suchen wie document.addEventListener oder .keycode-Eigenschaft (nicht 100% zuverlässig).
• Browser-eigene Shortcuts können Testverfahren stören (z.B. Shift+/ öffnet Firefox-Suche).
• Bei Browser-Störungen: ESC drücken oder auf leeren Seitenbereich klicken, um Fokus aus Browser-Suche zu entfernen.

1. Auto-Aktualisierung / Redirect prüfen: Im Seitenquelltext (head) nach meta http-equiv="refresh" suchen. Wenn vorhanden und content > 0 → prüfen, ob Abschalt- oder Anpassungsmöglichkeit existiert. content="0" ohne URL → keine zeitliche Begrenzung. Sofortige Weiterleitungen mit URL (content="0;url=...") können andere Kriterien betreffen.
2. Sichtbare Zeitbegrenzungen prüfen: Wird eine verbleibende Zeit angezeigt (z. B. Session-Ende, Formular-Abgabe)? Setzen Interaktionen die Zeit zurück oder verlängern sie diese? Erscheint ≥ 20 s vor Ablauf ein Hinweis/Popup mit Verlängerungsoption oder Deaktivierung?
3. Nicht sichtbare Sessions prüfen: Interaktive Seite (z. B. Formular) 20 Minuten inaktiv lassen. Prüfen: Vor Ablauf Warnung oder Verlängerungsoption vorhanden? Ausnahme: Daten bleiben > 20 m ohne Aktion erhalten. Keine nachträgliche Time-out-Meldung erst beim Absenden.
4. Zeitbegrenzte Statusmeldungen prüfen: Automatisch verschwindende Meldungen (z. B. „Gespeichert") identifizieren. Problematisch, wenn sie einzige Informationsquelle sind und zu kurz sichtbar → Alternative oder dauerhafte Anzeige nötig.

• Temporäre Statusmeldungen (wie Toast-Notifications) sind erlaubt, wenn es alternative dauerhafte Informationswege gibt.
• Beispiel: E-Mail-Eingangs-Toast ist akzeptabel, wenn Nutzer den Posteingang auch manuell abrufen können.
• Nur inhaltlich gesetzte Zeitbegrenzungen werden geprüft - externe Zeitbegrenzungen (Browser-Timeouts, Server außerhalb der Website) fallen nicht unter diese Anforderung.
• Problem bei der Prüfung: Zeitbegrenzungen sind oft nur serverseitig gesetzt und nicht im Quellcode der Seite erkennbar.

1. Identifizieren Sie alle bewegten, blinkenden, scrollenden oder automatisch aktualisierten Inhalte auf der Webseite.
2. Beobachten Sie unmittelbar nach dem Laden der Seite, ob diese Inhalte automatisch innerhalb von 5 Sekunden stoppen.
3. Falls die Bewegung/Aktualisierung länger als 5 Sekunden andauert und nicht als „essenziell" eingestuft ist: Suchen Sie nach einem gut sichtbaren Button oder Link (idealerweise am Anfang des bewegten Inhalts oder Kontextes), der es ermöglicht, die Bewegung zu pausieren, zu stoppen, auszublenden oder bei automatisch aktualisierten Inhalten die Aktualisierungsfrequenz zu steuern.
4. Aktivieren Sie den Mechanismus und prüfen Sie, ob die Bewegung/Aktualisierung tatsächlich anhält und nicht von selbst erneut startet, außer bei erneuter Aktivierung durch die Nutzer.
5. (Optional) Testen Sie, ob bei erneuter Aktivierung die Bewegung fortsetzbar an der letzten Position ist.
6. Beachten Sie, dass technische Einschränkungen erlauben, dass Inhalte, die zwischen Pause und Wiederaufnahme erzeugt werden, nicht unbedingt angezeigt werden müssen.

• Stop-Schaltfläche muss deutlich sichtbar und eindeutig beschriftet sein.
• Empfohlene Platzierung: Am Seitenbeginn oder in direktem Kontext des bewegten Inhalts.
• Nach dem Stoppen müssen alle Inhalte weiterhin vollständig verfügbar bleiben.
• Regel gilt gleichermaßen für Werbung und redaktionelle Inhalte - keine Unterscheidung.

1. Überprüfen, ob im Webinhalt zeitliche Begrenzungen existieren, die Nutzer einschränken.
2. Bewerten, ob vorhandene Zeitbegrenzungen zu den definierten Ausnahmen (nicht-interaktive synchronisierte Medien oder Echtzeit-Ereignisse) gehören.
3. Falls keine Ausnahme zutrifft, ist das Erfolgskriterium nicht erfüllt.

• Wichtige Ausnahmen: Nicht-interaktive synchronisierte Medien (z. B. reine Informationsvideos) und Echtzeit-Ereignisse (z. B. Live-Übertragungen, Online-Auktionen, virtuelle Welten).
• Das Kriterium erweitert die Anforderungen aus WCAG 2.2.1 und 2.2.2 um eine noch strengere Vorgabe für maximale Zugänglichkeit.

1. Öffnen Sie die zu prüfende Webseite in Ihrem Webbrowser.
2. Durchsuchen Sie die Webseite nach Elementen oder Prozessen, die eine Unterbrechung darstellen könnten: Automatisch aufpoppende Dialogfenster oder Meldungen (z. B. Cookie-Banner, Newsletter-Anmeldungen, Live-Chat-Anfragen), die nicht direkt durch eine Nutzeraktion ausgelöst wurden, unerwartete Änderungen im Inhalt oder Kontext, die nicht durch Benutzeraktionen hervorgerufen wurden, Push-Benachrichtigungen oder Systemmeldungen, die im Browser oder auf der Seite erscheinen.
3. Prüfen Sie bei jeder identifizierten nicht-notfallbezogenen Unterbrechung, ob ein Mechanismus zur Verfügung steht, um diese zu verschieben oder zu unterdrücken.
4. Wenn eine Unterbrechung auftritt, die als Notfall klassifiziert wird, prüfen Sie kritisch, ob diese Klassifizierung tatsächlich der Definition entspricht.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie eine authentifizierte Webseite oder Anwendung, bei der eine Anmeldung erforderlich ist.
2. Starten Sie eine länger andauernde Aktivität (z. B. Formular ausfüllen, Warenkorb füllen).
3. Lassen Sie die Sitzung absichtlich ablaufen, z. B. durch Inaktivität oder erzwingen Sie einen Logout.
4. Melden Sie sich erneut an (Neu-Authentifizierung).
5. Prüfen Sie, ob die begonnene Aktivität an der gleichen Stelle fortgesetzt werden kann und ob keine Daten verloren gegangen sind (z. B. Eingaben im Formular, Warenkorbinhalt).
6. Vergewissern Sie sich, dass der Nutzer nicht gezwungen ist, die Aktivität komplett neu zu beginnen.

Keine besonderen Hinweise für dieses Kriterium.

1. Identifizieren Sie Bereiche der Webanwendung mit längeren datenrelevanten Aktivitäten (z. B. Formulare, Warenkorb, mehrstufige Prozesse).
2. Starten Sie eine Aktivität und geben Sie Daten ein oder ändern Sie den Zustand.
3. Simulieren Sie Inaktivität, die zu einem Timeout führen kann.
4. Prüfen Sie bei Timeouts unter 20 Stunden, ob eine Warnmeldung erscheint, die die Dauer der Inaktivität angibt, und vor dem drohenden Datenverlust warnt.
5. Prüfen Sie bei Timeouts ab 20 Stunden, ob die Daten ohne Benutzeraktion erhalten bleiben, auch wenn keine Warnung erfolgt.
6. Melden Sie sich bei Ablauf der Sitzung ggf. erneut an und prüfen Sie, ob die Daten erhalten bleiben und die Aktivität fortgesetzt werden kann.

Keine besonderen Hinweise für dieses Kriterium.

1. Beobachten Sie die Webseite sorgfältig auf visuelle Elemente mit schnellen Helligkeits- oder Farbwechseln (Flashes).
2. Prüfen Sie, ob diese Flashes innerhalb einer beliebigen Ein-Sekunden-Periode mehr als drei „general flashes" oder „red flashes" umfassen.
3. Prüfen Sie die Größe der blinkenden Flächen: Überschreiten die Flashes zusammen mehr als 0,006 Steradiant innerhalb eines 10-Grad-Sichtfelds (ca. 25 % des Bereichs), gilt das Kriterium als nicht erfüllt.
4. Ausnahmen: Flashes in feinen Mustern (z. B. Schachbrettmuster mit Quadraten < 0,1 Grad Sichtfeld) gelten nicht als Verstoß.
5. Für Grenzfälle oder komplexe Inhalte verwenden Sie geeignete Messwerkzeuge zur Validierung.

• Größere flackernde Bereiche führen zur Abwertung der gesamten Webseitenprüfung.

1. Prüfung erfolgt durch Beobachtung aller flackernden Inhalte auf mehr als drei Flashes pro Sekunde, unabhängig von Helligkeit, Farbe oder Größe.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die zu prüfende Webseite im Browser.
2. Führen Sie gezielte Interaktionen durch (z. B. Klick auf Buttons, Scrollen, Hover über Menüs), um festzustellen, ob Bewegungsanimationen auftreten.
3. Unterscheiden Sie zwischen Bewegungsanimation und reinem Farb-/Deckkraftwechsel (letzteres fällt nicht unter das Kriterium).
4. Prüfen Sie, ob eine Möglichkeit vorhanden ist, diese Animationen zu deaktivieren:
   • Direkt auf der Website (z. B. globaler Einstellungsschalter)
   • Über erkannte und respektierte Betriebssystemeinstellungen
5. Falls eine Animation laut Anbieter „unerlässlich" ist, bewerten Sie, ob deren Entfernung die Funktion oder den Informationsgehalt tatsächlich grundlegend verändern würde und ob keine alternative barrierefreie Lösung möglich ist.
6. Wiederholen Sie die Tests mit deaktivierten Animationen, um sicherzustellen, dass die Funktionalität erhalten bleibt.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die zu prüfende Webseite.
2. Navigieren Sie per Tastatur (Tab-Taste) vom Seitenanfang.
3. Prüfen Sie, ob ein sichtbarer oder beim Fokuserhalt eingeblendeter „Skip-Link" oder ein vergleichbarer Mechanismus vorhanden ist.
4. Aktivieren Sie den Skip-Link und prüfen Sie, ob der Fokus direkt zum Hauptinhalt springt und die wiederholten Navigationsbereiche umgeht.
5. Alternativ prüfen Sie, ob der Hauptinhalt korrekt mit Landmark-Rollen oder Ankern ausgezeichnet ist, sodass Screenreader-Nutzer direkt dorthin springen können.
6. Wiederholen Sie den Test auf mehreren Unterseiten, um sicherzustellen, dass der Mechanismus konsistent funktioniert.

• Eigenständige Bereiche sind: Navigationsbereiche, Hauptinhaltsbereich, Zusatzinhalte, Fußbereich.
• Fußbereich gilt nicht als eigenständiger Bereich, wenn dort nur redundante Links, Copyright-Hinweise oder Datumsangaben stehen.
• Sprunglinks und ARIA-Landmarks sind nicht grundsätzlich erforderlich - abhängig von Inhalt und Komplexität der Seite.
• Mehrfach verwendete Landmarks (z.B. mehrere nav-Elemente) brauchen aussagekräftige Bezeichnungen über aria-label oder aria-labelledby.
• Breadcrumb-Navigation benötigt vorangestellte Kennzeichnung wie "Sie sind hier" oder "Navigationspfad" (kann versteckt sein für Screenreader).
• iframe-Elemente: title-Attribut soll Zweck oder Inhalt beschreiben ("Werbung", "Social Media"), nicht die Position ("rechts", "oben").

1. Öffnen Sie die zu prüfende Webseite im Browser.
2. Rufen Sie den Quelltext oder die Entwicklertools auf (z. B. mit F12 oder Rechtsklick → "Seitenquelltext anzeigen").
3. Suchen Sie im head-Bereich nach dem title-Element.
4. Prüfen Sie den Inhalt:
   • Ist der Titel aussagekräftig und beschreibt er klar den Inhalt/Zweck der Seite?
   • Besteht er nicht nur aus generischen Begriffen wie „Startseite" oder ausschließlich dem Domainnamen?
5. (Optional) Lesen Sie den Titel mit einem Screenreader oder im Lesezeichen-Dialog vor:
   • Wird das Hauptthema der Seite klar vermittelt?
   • Lässt sich die Seite eindeutig von anderen Seiten derselben Website unterscheiden?

• Titel muss nicht den kompletten Navigationspfad von der Startseite zur aktuellen Seite wiedergeben.
• Guter Titel soll die Seite in Bookmark-Listen sinnvoll vertreten können.
• Empfohlene Struktur: Seitenname - Webseitenname (erst Spezifisches, dann Allgemeines).
• Beispiel: "Kontakt - Musterfirma GmbH" statt nur "Kontakt"

1. Seite am logischen Startpunkt (z. B. ganz oben) aufrufen.
2. Mit der Tab-Taste durch alle fokussierbaren Elemente navigieren (Links, Buttons, Formularfelder, Bedienelemente etc.).
3. Prüfen, ob die Fokusreihenfolge:
   • einer logischen visuellen und inhaltlichen Abfolge folgt (bei LTR-Sprachen: von oben nach unten, von links nach rechts),
   • innerhalb zusammenhängender Inhaltsbereiche bleibt,
   • in Formularen der erwarteten Eingabereihenfolge entspricht.
4. Prüfen, ob die Reihenfolge Bedeutung und Bedienbarkeit erhält (keine Sprünge zwischen unzusammenhängenden Bereichen, keine Sackgassen oder unerwarteten Fokuswechsel).
5. Mit Shift + Tab die umgekehrte Fokusreihenfolge kontrollieren.
6. Besondere Fälle testen: Modale Dialoge / Pop-ups, Dynamische Inhalte, Sprunglinks.

• Tab-Reihenfolge soll im Wesentlichen der visuellen Anordnung auf dem Bildschirm folgen.
• Kleinere Abweichungen sind akzeptabel, wenn sie logisch nachvollziehbar sind.
• Unsichtbare Sprunglinks hintereinander erschweren die Nachvollziehbarkeit der Tab-Reihenfolge.
• Bei schlechter Fokus-Sichtbarkeit: "Show Tab Focus"-Bookmarklet von Jeff Smith zur Hervorhebung verwenden.
• Wichtiger Prüfhinweis: Fokus muss per F6 ins Browser-Fenster geholt werden, nicht per Mausklick (verfälscht sonst den Test).
• Dropdown-Listen mit onchange-Verhalten: Alt + Pfeil nach unten zum sicheren Durchblättern verwenden.
• Orientierung für Widget-Verhalten: ARIA Authoring Practices Guide konsultieren

1. Navigieren Sie durch die gesamte Webseite und identifizieren Sie alle Links.
2. Prüfen Sie, ob der Linktext allein den Zweck oder das Ziel des Links eindeutig beschreibt.
3. Falls der Linktext allein nicht aussagekräftig ist, prüfen Sie, ob der Zweck durch den programmatisch ermittelbaren Kontext erkennbar wird:
   • Typische Quellen für diesen Kontext: Text im selben Absatz, Listeneintrag oder derselben Tabellenzelle wie der Link.
   • Text in einer verknüpften Tabellenkopfzelle.
   • Kontext aus dem Satz, in dem sich der Link befindet.
   • Simulieren Sie die Nutzung mit einem Screenreader, um zu prüfen, ob der Kontext korrekt vorgelesen wird.
4. Prüfen Sie, ob Links vorliegen, deren Zweck allgemein mehrdeutig ist (selbst für Nutzende ohne Behinderung). Solche Links sind eine Ausnahme und gelten als konform.

• URLs und E-Mail-Adressen sind durch ihr Format selbsterklärend und werden nicht negativ bewertet.
• Bei verlinkten Grafiken: Der alt-Text des Bildes fungiert als Linktext.
• Unspezifische Links wie "mehr", "weiter" in Listenelementen sind akzeptabel, wenn der Kontext aus der Umgebung klar hervorgeht.
• Als Kontext gelten: umschließender Absatz, Listenpunkt oder vorangehende Überschrift.
• Mit display:none versteckter zusätzlicher Linktext wird von Screenreadern ignoriert und verbessert die Aussagekraft nicht.
• Das title-Attribut von Links wird nicht zuverlässig von allen Screenreadern ausgewertet (abhängig von Einstellungen).

1. Prüfen Sie, ob mindestens zwei der folgenden Mechanismen verfügbar sind:
   • Durchgängig sichtbare, hierarchische Navigationsmenüs (z. B. Hauptnavigation, Breadcrumbs)
   • Inhaltsverzeichnis (Sitemap) oder Seitenübersicht
   • Suchfunktion (Suchfeld direkt auf der Seite oder Link zu Suchseite)
   • Vollständige Seitenliste, verlinkt von der Startseite oder auf Unterseiten
   • Sequenzielle Navigation („Zurück" / „Weiter") über die gesamte Seitenmenge hinweg
   • Prozessnavigation (nur bei klar abzugrenzenden Workflows)
2. Nutzen Sie jeden identifizierten Weg stichprobenhaft und stellen Sie sicher, dass er tatsächlich zum Aufruf von Inhalten führt.
3. Bestätigen Sie, dass mindestens zwei unterschiedliche Zugangswege existieren, die sich gegenseitig ergänzen (z. B. Menü + Suche).

• Hierarchische Menüs müssen nicht alle Unterebenen der Website vollständig abbilden.
• Die Kombination aus Hauptmenü plus Bereichsmenü gilt als ein einziger Zugangsweg.
• Breadcrumb-Navigation gilt nicht als eigenständiger Zugangsweg (ermöglicht nur Navigation aufwärts, nicht zu tieferen Ebenen).
• Bei kleinen Websites: Startseite mit vollständiger Verlinkung zu allen Unterseiten kann als Sitemap fungieren.
• Sequenzielle Prozesse (Checkout, Registrierung): Fehlende weitere Navigationsmöglichkeiten sind nicht negativ zu bewerten, da Seiten nur im Prozesskontext Sinn machen

1. Überschriften prüfen:
   • Nutzen Sie ein Überschriften-Bookmarklet („Inhalte gegliedert") oder die Developer Tools, um die Hierarchie und den Wortlaut aller h1–h6-Elemente zu überprüfen.
   • Stellen Sie sicher, dass jede Überschrift den unmittelbar folgenden Abschnitt treffend beschreibt und nicht nur dekorativ ist.
2. Beschriftungen von Formularelementen prüfen:
   • Kontrollieren Sie für jedes Eingabefeld, jede Checkbox, jedes Radio-Element und jede Schaltfläche, dass ein zugeordnetes label, aria-label oder aria-labelledby existiert.
   • Prüfen Sie, ob der sichtbare Labeltext (oder das aria-label) Zweck und erwarteten Inhalt des Felds eindeutig vermittelt.
3. Gruppenbeschriftungen (fieldset/legend) prüfen:
   • Verifizieren Sie bei Feldgruppen (z. B. Radio-Gruppen), dass ein fieldset mit einem sinnvollen legend eingesetzt wird.
4. Verborgene Labels und ARIA prüfen:
   • Suchen Sie in den Developer Tools nach aria-label und aria-labelledby und bewerten Sie deren Aussagekraft und Sprache.

• Bei Fachanwendungen: Fachbegriffe, Abkürzungen und Codes sind für die Zielgruppe akzeptabel.
• Fachsprache bringt Vorteile mit sich: Wiedererkennbarkeit, Präzision und Kürze.
• Muss nicht allgemeinverständlich sein, wenn es für die spezifische Zielgruppe aussagekräftig ist.
• Fachausdrücke müssen erlernt werden, das ist bei entsprechenden Anwendungen vertretbar

1. Mit Tabulator alle interaktiven Elemente (Links, Buttons, Formulare) durchgehen und prüfen, ob eine visuelle Fokushervorhebung vorhanden ist (z. B. Rahmen, Outline, Farbwechsel, Unterstreichung, Icon).
2. Prüfen, ob versteckte Sprunglinks bei Fokuserhalt eingeblendet werden.
3. Erkennt die Hervorhebung ausschließlich über Farbwechsel: Für Level AA muss die Sichtbarkeit klar erkennbar sein.
4. Prüfen, ob der Standard-Browser-Fokus (outline) auf individuellen Hintergründen gut sichtbar ist.
5. Falls unklar, Kontrast mit Developer-Tools messen: Ist der Fokusindikator ein grafisches Element, muss der Kontrast zu angrenzenden Farben ≥ 3:1 sein.
6. Schritte 1–5 in Chrome wiederholen, um Browser-Konsistenz zu prüfen.

• Test muss mit aktiviertem JavaScript erfolgen, da Scripts die Fokushervorhebung beeinflussen können.
• Kompletter Verlust des Tastaturfokus (durch JavaScript blur() oder CSS outline:none) ist ein Fehler.
• Standard-Browser-Fokus ist grundsätzlich ausreichend, kann aber bei gestalteten Hintergründen schlecht sichtbar sein.
• Gezielte CSS-Gestaltung über :focus-Pseudoklasse stellt bessere Sichtbarkeit sicher.
• Bei Fokus-Hervorhebung nur über Farbänderung: Kontrast von mindestens 3:1 zum unfokussierten Zustand erforderlich.
• Wenn Standard-Browser-Fokus sichtbar ist: Prüfschritt erfüllt (eventuelle Kontrastprobleme werden in Prüfschritt 9.1.4.11 bewertet)

1. Durch verschiedene Seiten navigieren (z. B. Unterseiten, Kapitel, Schritte im Bestellprozess).
2. Visuelle Prüfung auf Standortinformationen:
   • Breadcrumb-Navigation: Ist sie vorhanden und zeigt den Pfad von der Startseite zur aktuellen Seite? Sind die Schritte klar beschriftet? Ist der letzte Eintrag als aktuelle Seite erkennbar?
   • Hervorhebung in Haupt-/Sekundärnavigation: Ist der Link zur aktuellen Seite visuell hervorgehoben?
   • Seitenüberschriften und -titel: Gibt der title und/oder die h1-Überschrift Aufschluss über die aktuelle Seite im Kontext des gesamten Satzes?
   • Sitemap oder Inhaltsverzeichnis: Gibt es einen leicht zugänglichen Link zu einer Sitemap?
3. Programmatische Prüfung (optional): Mit Entwicklertools prüfen, ob Standortinformationen semantisch korrekt ausgezeichnet sind.
4. Prüfung mit Hilfstechnologien (Screenreader): Navigation mit Screenreader testen.
5. Konsistenzprüfung: Sicherstellen, dass Standortinformationen und deren Darstellung über alle Seiten eines Satzes konsistent sind.

Keine besonderen Hinweise für dieses Kriterium.

1. Identifikation aller Links: Alle Links eines „Satzes von Webseiten" erfassen (Text, Bilder, Skripte).
2. Visuelle Prüfung des Linktexts isoliert:
   • Jeden Linktext ohne Kontext betrachten.
   • Frage: Ist der Zweck des Links aus dem Text klar erkennbar?
3. Prüfung mit Screenreader (Kontextunabhängigkeit):
   • Mit Screenreader nur Links auf der Seite navigieren.
   • Sicherstellen, dass Linkzweck ohne Kontext erkennbar ist.
4. Prüfung der Ausnahme „Mehrdeutig für alle Benutzer":
   • Links, deren Zweck nicht klar ist, auf diese Ausnahme prüfen.
5. Code-Prüfung (bei Bildlinks): Bildlinks müssen ein aussagekräftiges alt-Attribut haben, das den Linkzweck beschreibt.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die zu prüfende Webseite in einem Webbrowser.
2. Analysieren Sie den Textinhalt der Seite auf logische Abschnitte.
3. Prüfen Sie, ob jeder sinnvolle Abschnitt eine eigene Überschrift besitzt, die den Inhalt klar beschreibt.
4. Überprüfen Sie die korrekte hierarchische Struktur der Überschriften (h1 als Hauptüberschrift, h2 als Unterabschnitt etc.).
5. Prüfen Sie mit Hilfe der Entwicklertools, ob die Überschriften semantisch mit den entsprechenden HTML-Tags ausgezeichnet sind und nicht nur optisch durch Schriftformatierung realisiert werden.
6. (Optional) Nutzen Sie einen Screenreader, navigieren Sie mit der Überschriften-Navigation (z.B. Taste „H") und prüfen Sie, ob die Überschriftenstruktur logisch und vollständig wiedergegeben wird.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die Webseite in Firefox.
2. Navigieren Sie mit Tab und Umschalt + Tab durch alle interaktiven Elemente (Links, Buttons, Formulare).
3. Beobachten Sie, ob der Tastaturfokus eines Elements jemals vollständig von anderen Inhalten verdeckt wird (z. B. Sticky-Header, Cookie-Hinweis, nicht-modale Dialoge).
4. Falls eine vollständige Verdeckung auftritt, prüfen Sie, ob der Nutzer das verdeckte fokussierte Element ohne Fokusverlust wieder sichtbar machen kann, z. B. durch:
   • Drücken der Escape-Taste (zum Schließen von Overlays/Popups)
   • Scrollen
   • Einen definierten Tastaturbefehl zum Wechsel zwischen Overlay und Hauptinhalt
5. Wiederholen Sie Schritte 1–4 im Chrome-Browser.

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die Webseite in gängigen Browsern (z. B. Firefox, Chrome), idealerweise auf Desktop und mobil.
2. Stellen Sie den Browserzoom auf 100 %.
3. Finden Sie alle interaktiven Benutzeroberflächenkomponenten, die den Fokus erhalten können: Links, Buttons, Formularfelder, Widgets, etc.
4. Navigieren Sie mit Tab und Umschalt + Tab durch alle interaktiven Elemente.
5. Prüfen Sie bei jedem Fokus, ob der Fokusindikator sichtbar ist.
6. Kontrollieren Sie, ob irgendein Teil des fokussierten Elements – inklusive Fokusindikator – durch autorseitige Inhalte verdeckt wird.
7. Achten Sie darauf, ob die Seite automatisch scrollt, um das Element sichtbar zu machen. Bleibt das Element verdeckt, liegt ein Fehler vor.
8. Wiederholen Sie die Navigation und Prüfung bei vergrößertem Zoom (z. B. 200 %, 400 %).

Keine besonderen Hinweise für dieses Kriterium.

1. Webseite in gängigen Browsern öffnen.
2. Mit Tastatur (Tab und Umschalt + Tab) alle interaktiven Elemente (Links, Buttons, Formularfelder, Menüpunkte etc.) durchlaufen.
3. Visuell und mit Entwickler-Tools Fokusindikator bei jedem fokussierten Element prüfen:
   • Ist die Größe des Fokusindikators mindestens so groß wie der Umriss eines 2px dicken Rahmens des Elements?
   • Ist das Kontrastverhältnis des Fokusindikators gegenüber dem nicht fokussierten Zustand mindestens 3:1?
4. Prüfen, ob das Element unter eine der Ausnahmen fällt (kein Einfluss durch Autor).

Keine besonderen Hinweise für dieses Kriterium.

1. Öffnen Sie die zu prüfende Webseite im Browser auf einem Touch-fähigen Gerät.
2. Identifizieren Sie Funktionen, die komplexe Zeiger-Gesten verwenden, z. B.:
   • Karussells oder Slider, die per Wischen (pfadbasierte Geste) gesteuert werden.
   • Kartenanwendungen mit Mehrpunkt-Gesten wie Zwei-Finger-Spreizen zum Zoomen.
   • Rand-Wischmenüs, die nur durch bestimmte Wischbewegungen bedient werden können.
   • Drag-and-Drop-Funktionen, bei denen Elemente durch Ziehbewegungen verschoben werden.
3. Für jede gefundene komplexe Geste prüfen Sie, ob eine alternative Bedienmöglichkeit per einfacher Zeigereingabe vorhanden ist.
4. Testen Sie, ob die alternativen Bedienelemente die gleiche Funktion auslösen können.
5. Unterscheiden Sie Gesten, die vom Browser oder Assistiven Technologien gesteuert werden (System-Gesten), von Webinhalts-Gesten.
6. Beachten Sie die Ausnahme für „essenziell" komplexe Gesten.

• Test auf verschiedenen Geräten erforderlich (Desktop und mobile Geräte), da Alternativen möglicherweise nur in bestimmten Umgebungen verfügbar sind.
• Alternativen zur Aktivierung über einfache Zeiger-Gesten müssen in allen relevanten Systemumgebungen und Browsern funktionieren.
• Ausnahme: Funktionen, die natürlich und notwendigerweise auf komplexen Pfaden basieren (Beispiel: Eigene Unterschrift zeichnen)

1. Verwenden Sie ein Smartphone, Tablet oder eine Maus an einem Desktop-PC.
2. Öffnen Sie die Webseite mit interaktiven Elementen.
3. Berühren bzw. klicken Sie auf ein interaktives Element und halten Sie den Zeiger (Finger oder Maus) auf dem Element, ohne loszulassen.
4. Beobachten Sie, ob beim Down-Event bereits eine Aktion gestartet wird.
5. Wenn ja, prüfen Sie, ob die Aktion vor Abschluss abgebrochen oder nach Abschluss widerrufen werden kann, z. B. durch:
   • Wegziehen des Zeigers vor Loslassen (Abbruch vor Fertigstellung)
   • Bestätigungsdialog mit Abbrechen-Option zwischen Down- und Up-Event
   • Loslassen außerhalb eines gültigen Drop-Ziels (bei Drag-and-Drop springt das Element zurück)
   • Undo-Funktion nach Fertigstellung (Widerruf nach Fertigstellung)
   • Umkehrung der Aktion beim Up-Event
6. Bewerten Sie, ob die Aktion essenziell ist und somit keine Alternative notwendig ist.

• Stichprobenartige Prüfung ist ausreichend, wenn die Umsetzung gleichartig ist.
• Für jede Art von Menüeintrag (Hauptmenü, Untermenü) und Linktyp ein Element testen.
• Browser-Kontextmenüs, die beim Test aufgerufen werden, sind nicht Teil der Prüfung und sollen ignoriert werden.
• Zeiger-Down-Events sind: mousedown, touchstart und pointerdown

1. Öffnen Sie die Webseite und identifizieren Sie alle interaktiven Elemente mit sichtbarer Beschriftung (z. B. Links, Buttons, Formular-Labels, Checkboxen).
2. Ermitteln Sie für jedes Element den zugänglichen Namen mittels Screenreader (z. B. NVDA im Learn-Modus) oder Browser-Entwicklertools im Accessibility-Bereich.
3. Vergleichen Sie die sichtbare Beschriftung mit dem zugänglichen Namen:
   • Die sichtbare Beschriftung muss exakt wortgleich (inkl. Groß-/Kleinschreibung, Sonderzeichen) im zugänglichen Namen enthalten sein.
   • Zusätzlicher Text im zugänglichen Namen ist erlaubt, darf aber die Übereinstimmung des sichtbaren Texts nicht verhindern.
4. Stellen Sie sicher, dass zusätzliche Texte den sichtbaren Text nicht überlagern oder ersetzen.

• Screenreader, Browser-Entwicklertools oder Bookmarklet zur Ermittlung des zugänglichen Namens nutzen.
• Beachten: Screenreader-Ausgabe kann zusätzliche Informationen enthalten (Rolle des Elements, zusätzliche Beschreibung), die nicht Teil des zugänglichen Namens sind.
• Sichtbare Beschriftung muss in exakt derselben Zeichenfolge im zugänglichen Namen enthalten sein.
• Zugänglicher Name darf zusätzlichen Text haben, aber der sichtbare Beschriftungstext muss wortgleich vorkommen

1. Analysieren Sie den Quellcode auf Sensor-Events wie deviceorientation, devicemotion, proximity oder Kamera-APIs.
2. Testen Sie die Webseite auf einem mobilen Gerät oder Emulator durch typische Bewegungen (Neigen, Schütteln etc.).
3. Beobachten Sie, ob und wie die Seite auf Bewegungen reagiert (z. B. Änderungen, Aktionen, Navigation).
4. Für jede bewegungsbasierte Funktion prüfen, ob eine gleichwertige Alternative über herkömmliche UI-Komponenten (Buttons, Slider, Checkboxen, Dropdowns) existiert.
5. Sicherstellen, dass die alternative Bedienung dieselbe Funktionalität und das gleiche Ergebnis bietet.
6. Prüfen, ob die alternativen UI-Komponenten barrierefrei sind (Tastaturbedienbarkeit, Fokusindikatoren, Screenreader-Name/Rolle).
7. Suchen Sie eine leicht zugängliche Option (z. B. in „Einstellungen", „Barrierefreiheit"), um Bewegungssteuerung zu deaktivieren.
8. Testen Sie die Deaktivierung und prüfen Sie, ob die Bewegungserkennung danach nicht mehr reagiert, während alternative Bedienelemente weiter funktionieren.
9. Prüfen Sie, ob die Bewegungserkennung über eine barrierefreiheitsunterstützte Schnittstelle realisiert wird oder ob sie „essentiell" ist.

Keine besonderen Hinweise für dieses Kriterium.

1. Systematisch alle interaktiven Elemente der Seite/Webanwendung identifizieren, die per Zeigereingabe bedienbar sind (z. B. Buttons, Links, Formularfelder, Slider, Hotspots, klickbare Bilder).
2. Mithilfe der Entwicklertools die gerenderte Breite und Höhe jedes Zielbereichs in CSS-Pixeln messen.
3. Sicherstellen, dass die Größe mindestens 44 x 44 CSS-Pixel beträgt.
4. Bei überlappenden Zielen wird der überlappende Bereich nur dann berücksichtigt, wenn beide dieselbe Funktion auslösen.
5. Für alle Elemente kleiner als 44 x 44 CSS-Pixel prüfen, ob eine der folgenden Ausnahmen zutrifft:
   • Gleichwertige Alternative: Existiert auf derselben Seite eine gleichwertige Bedienmöglichkeit mit mindestens 44 x 44 CSS-Pixel, die leicht auffindbar ist?
   • Inline-Element: Handelt es sich um ein Element innerhalb eines Fließtextes (z. B. ein Link im Satz), bei dem die Größe durch die Textzeilenhöhe begrenzt ist?
   • Benutzeragent-Kontrolle: Wird die Größe vom Browser oder Betriebssystem vorgegeben und nicht vom Autor verändert (z. B. Standard-Radio-Buttons)?
   • Essentielle Darstellung: Würde eine größere Darstellung die Funktion oder Information grundlegend verändern oder ungültig machen?

Keine besonderen Hinweise für dieses Kriterium.

1. Testen Sie die Webseite/Webanwendung mit mehreren Eingabemodalitäten gleichzeitig oder in schnellem Wechsel (z. B. Tastatur + Maus, Maus + Touch).
2. Achten Sie darauf, ob das Umschalten blockiert wird oder eine Modalität nach Nutzung einer anderen nicht mehr funktioniert.
3. Prüfen Sie, ob Funktionen wie Copy & Paste in Eingabefeldern eingeschränkt werden, sofern keine Sicherheitsgründe vorliegen.
4. Beobachten Sie, ob Eingabegeräte plötzlich nur eingeschränkt funktionieren (z. B. Touchpad akzeptiert nur noch bestimmte Gesten).
5. Ist eine Einschränkung vorhanden, muss sie einer der drei Ausnahmen zugeordnet werden können:
   • Essentiell: Die Einschränkung ist notwendig, da ohne sie die Funktionalität verloren geht und keine alternative konforme Umsetzung möglich ist.
   • Sicherheit: Die Einschränkung ist erforderlich, um die Sicherheit sensibler Inhalte zu gewährleisten (z. B. Finanztransaktionen).
   • Nutzereinstellungen: Die Einschränkung resultiert aus Nutzereinstellungen auf Plattform/Betriebssystem/Browser und wird nicht vom Autor erzwungen.
6. Erfassen Sie die getesteten Eingabemodalitäten und festgestellte Einschränkungen.

Keine besonderen Hinweise für dieses Kriterium.

1. Prüfen, ob Elemente auf der Webseite mittels Ziehbewegung verschoben, sortiert oder abgelegt werden müssen (z. B. Drag-and-Drop-Listen, frei verschiebbare Objekte, Slider mit Drag-Knopf).
2. Visuell nach Interaktionen suchen, die „Greifen-und-Ziehen"-Gesten erfordern.
3. Für jede Drag-Funktion testen, ob das gleiche Ergebnis durch Tippen/Klicken oder eine Folge solcher Aktionen erreicht werden kann.
4. Mögliche alternative Bedienkonzepte prüfen:
   • Nach einfachem Klick öffnet sich ein Kontext- oder Aktionsmenü zur Auswahl der Zielposition oder Aktion.
   • Pfeilsymbole neben dem Element erlauben schrittweises Verschieben vor-/zurück.
   • Bei Slidern führt ein Klick auf die Schiene (Track) zum direkten Positionswechsel.
   • Direkte Eingabe eines Positionswerts über eine Eingabemaske.
5. Alle Drag-Funktionen und ihre jeweiligen Alternativen dokumentieren.

Keine besonderen Hinweise für dieses Kriterium.

1. Alle Elemente erfassen, die per Zeiger bedient werden können (z. B. Buttons, Links, Icons, andere UI-Komponenten).
2. Mit Browser-Inspektor (Rechtsklick → Untersuchen) Höhe und Breite prüfen. Dabei Padding und Border berücksichtigen.
3. Maße in CSS-Pixeln messen und Mindestgröße von 24 × 24 CSS-Pixel prüfen.
4. Kleinere Ziele sind nur zulässig, wenn eine der folgenden Ausnahmen zutrifft:
   • Spacing: Ein imaginärer 24-Pixel-Kreis um jedes Ziel überschneidet keine anderen Ziele.
   • Equivalent: Die Funktion ist über ein anderes, ausreichend großes Bedienelement erreichbar.
   • Inline: Das Ziel ist ein Inline-Link im Fließtext (abhängig von Zeilenhöhe).
   • User Agent Control: Zielgröße wird vom Browser/OS vorgegeben (native Controls).
   • Essential: Gesetzlich oder gestalterisch notwendige Darstellung, die nicht konform geändert werden kann.
5. Räumlich selektive Ziele (z. B. Slider) gelten als ein Ziel.
6. Alle nicht-konformen Ziele auflisten und begründen, ob sie Ausnahmen erfüllen oder angepasst werden müssen.

Keine besonderen Hinweise für dieses Kriterium.