Barrieren finden üben – an Beispielen, die es in sich haben

• Beispiel A – nicht erfüllt. Haken und Warndreieck sagen, welches Gerät läuft und welches nicht – diese Information steht nur im Bild. Mit alt="" sind die Symbole für den Screenreader unsichtbar: Er liest vier Gerätenamen ohne Zustand. Wer deshalb zum Kopierer läuft, steht vor einem defekten Gerät. Ein leeres alt ist nur richtig, wenn das Bild nichts beiträgt oder dasselbe direkt daneben als Text steht.
• Beispiel B – erfüllt. Dieselben Symbole, jetzt mit „In Betrieb:“ und „Außer Betrieb:“ als Alternativtext. Die Alternative nennt nicht das Aussehen („grüner Haken“), sondern die Bedeutung.
• Beispiel C – Galerie. Acht Stellen nicht erfüllt, zwei erfüllt:
  1. Stelle 1 – funktional, nicht erfüllt. Das Logo ist ein Link zur Startseite, und der Firmenname steht nur im Bild. „logo“ nennt weder Namen noch Ziel (Failure F30: Platzhalter statt Alternative). Verletzt außerdem 2.4.4 (der Zweck des Links ist nicht bestimmbar) und 2.5.3 (sichtbar steht „Stadtwerke Beispielstadt“, im Namen steht „logo“). Besser: alt="Stadtwerke Beispielstadt – Startseite".
  2. Stelle 2 – funktional, nicht erfüllt. Das Bild in der Schaltfläche hat kein alt-Attribut (F65), die Schaltfläche damit keinen Namen. Der Screenreader sagt „Schalter“ oder liest den Dateinamen. Verletzt außerdem 4.1.2. Besser: alt="Suchen" – der Name sagt, was passiert, nicht wie es aussieht („Lupe“).
  3. Stelle 3 – dekorativ, nicht erfüllt, geringe Schwere. Die Zierlinie trägt nichts bei, wird aber als „blaue Welle als Trennlinie“ vorgelesen (F39). Besser: alt="" oder als CSS-Hintergrund.
  4. Stelle 4 – komplex, nicht erfüllt. „Diagramm“ sagt, dass da ein Diagramm ist, aber nicht, was es zeigt; der Absatz darüber nennt die Zahlen auch nicht. Besser: eine kurze Alternative mit der Kernaussage („Balkendiagramm: Der Verbrauch ist im 1. und 4. Quartal am höchsten“) und die Werte als Text oder Tabelle direkt darunter: 1. Quartal 1.150 kWh, 2. Quartal 780 kWh, 3. Quartal 640 kWh, 4. Quartal 1.030 kWh – so umgesetzt in Beispiel F, Stelle 7.
  5. Stelle 5 – informativ, erfüllt. Der Alternativtext benennt, wer zu sehen ist. Weil der Name direkt daneben steht, wäre auch alt="" vertretbar – die Doppelansage ist ein Verbesserungshinweis, kein Verstoß.
  6. Stelle 6 – funktional, erfüllt. Beide Links haben einen Namen, der das Ziel nennt. Unschön: Zwei Links hintereinander führen zum selben Ziel, mit der Tastatur sind das zwei Stopps mit derselben Ansage. Verbesserung: ein gemeinsamer Link um Bild und Überschrift, das Bild mit alt="" (Technik H2).
  7. Stelle 7 – CAPTCHA, nicht erfüllt. „CAPTCHA“ benennt den Zweck nur für Eingeweihte, und es gibt keine Variante für einen anderen Sinn. Wer das Bild nicht sehen kann, kommt nicht weiter. Besser: alt="Sicherheitsabfrage: Zeichen aus dem Bild eingeben" und zusätzlich eine Hörfassung oder ein anderes Verfahren ohne Bild – siehe Beispiel F, Stelle 4.
  8. Stelle 8 – informativ, nicht erfüllt. „Jetzt wechseln und Bonus sichern“ steht nur im Hintergrundbild (F3). Im Barrierefreiheitsbaum gibt es an dieser Stelle nichts; schaltest du die Stile ab, verschwindet die Aussage. Verletzt außerdem 1.4.5: Der Satz ließe sich ohne Weiteres als Text setzen. Besser: der Satz als echter Text über einem Bild ohne Schrift – das behebt beides.
  9. Stelle 9 – funktional, nicht erfüllt. Drei Links, die nur aus einem SVG-Symbol bestehen: Rolle Link, Name leer. Der Screenreader sagt dreimal „Link“. Verletzt außerdem 2.4.4 und 4.1.2. Besser: am Link ein aria-label oder unsichtbarer Text mit dem Namen des Netzwerks, das SVG mit aria-hidden="true".
  10. Stelle 10 – informativ, nicht erfüllt. Die Sterne sind Zeichen einer Symbolschrift aus dem Unicode-Bereich für private Nutzung. Screenreader lesen nichts oder Unsinn; die Bewertung „4 von 5“ fehlt. Besser: Text „4 von 5 Sternen“, sichtbar oder für Screenreader, bzw. role="img" mit aria-label (Technik ARIA24) – siehe Beispiel F, Stelle 3.
• Beispiel D – erfüllt (Streitfall). Das Foto neben „Unsere Beratung“ zeigt irgendeine Person mit Headset. Es trägt nichts bei, was nicht in Überschrift und Text steht – also Dekoration, und alt="" ist genau richtig. Stimmung zu beschreiben ist eine redaktionelle Entscheidung, keine Pflicht. Ebenso vertretbar: „erfüllt nur, wenn das Foto nichts beiträgt“ – die Einordnung liegt bei den Autorinnen und Autoren.
• Beispiel E – formal nicht erfüllt, geringe Schwere. Kursposition: Ist das Bild rein dekorativ, müssen Hilfsmittel es übergehen können (F38); ein beschreibender Text wie „Beraterin am Telefon“ an einem Schmuckbild ist dann formal ein Verstoß (F39), behindert aber kaum – wie die Zierlinie in Stelle 3. Anders, wenn das Foto etwas aussagt, etwa weil es die tatsächliche Beraterin zeigt: Dann ist ein kurzer Text mit Name oder Funktion richtig. Immer nicht erfüllt: gar kein alt-Attribut (F65) oder ein Dateiname (F30).
• Beispiel F – Sonderformen und Gegenstücke. Die Stellen 1 bis 5 und 7 sind erfüllte Gegenstücke zu den Stellen 4 und 7 bis 10 der Galerie, Stelle 6 ist nicht erfüllt:
  1. Stelle 1 – erfüllt. Inline-SVG mit role="img" und aria-label: Im Baum steht „Grafik: WLAN“ und „Grafik: Steckdose an jedem Platz“. Ohne role="img" und Namen wäre ein Inline-SVG für Screenreader je nach Browser gar nichts oder eine namenlose Gruppe.
  2. Stelle 2 – erfüllt. Das Kalendersymbol schmückt nur den Linktext; mit aria-hidden="true" übergehen Hilfsmittel es. Der Link heißt „Veranstaltungskalender“.
  3. Stelle 3 – erfüllt. Dieselbe Symbolschrift wie in Stelle 10 der Galerie, aber in einem Element mit role="img" und aria-label="4 von 5 Sternen".
  4. Stelle 4 – erfüllt. Der Alternativtext nennt den Zweck, ohne die Lösung zu verraten – das erlaubt die CAPTCHA-Ausnahme. Dazu gibt es dieselbe Aufgabe für einen anderen Sinn, hier zum Anhören. Geht es um eine Anmeldung, kommt 3.3.8 hinzu.
  5. Stelle 5 – erfüllt. Der Werbesatz ist echter Text im HTML; das Hintergrundbild zeigt nur ein Muster. Ohne Stile bleibt der Satz stehen.
  6. Stelle 6 – nicht erfüllt. Beim Aktualisieren wechselt das Bild (8, dann 23, dann 37 von 40 Plätzen), der Alternativtext bleibt bei „8 von 40 Plätzen belegt“ stehen (F20). Wer das Bild nicht sieht, bekommt eine veraltete Auskunft. Der Alternativtext muss mit dem Bild wechseln.
  7. Stelle 7 – komplex, erfüllt. Dasselbe Diagramm wie in Stelle 4 der Galerie. Der Alternativtext nennt die Kernaussage und sagt, wo die Einzelwerte stehen; direkt darunter folgt eine Datentabelle mit allen vier Werten (Technik G74). Wer das Bild nicht sieht, bekommt dieselbe Information – und alle anderen können die Zahlen markieren und vergrößern.

Automatisch erkennbar? Teilweise. axe meldet in der Galerie Stelle 2 (Bild ohne alt, Schaltfläche ohne Namen) und Stelle 9 (drei Links ohne Namen) – sonst nichts. Ein vorhandener, aber unpassender Alternativtext („logo“, „Diagramm“, „CAPTCHA“), das leere alt an den Zustandssymbolen in Beispiel A, das Hintergrundbild, die Symbolschrift und der veraltete Text in Beispiel F rutschen durch. Werkzeuge finden fehlende Alternativen, nicht falsche.

Grenzfall: Ein Emoji im Text ist Text, kein Nicht-Text-Inhalt – der Screenreader liest seinen Namen. Als Aufzählungszeichen oder in langen Reihen ist das eine Frage der Verständlichkeit, meist kein Verstoß gegen 1.1.1. Und: Ein title-Attribut am Bild allein ist keine verlässliche Textalternative.

Verwandte Kriterien: 4.1.2 verlangt den Namen von Bedienelementen – bei Grafik-Schaltflächen und Symbol-Links trifft ein Befund oft beide Kriterien; im Bericht steht er beim Hauptkriterium, das andere wird als Querverweis genannt. 1.4.5 fragt, ob Text überhaupt als Bild vorliegen darf; 1.1.1 nur, ob das Bild eine Alternative hat. Für Audio und Video verlangt 1.1.1 lediglich eine beschreibende Kennzeichnung – den Rest regeln 1.2.1 bis 1.2.5.

• Beispiel A – nicht erfüllt. Eine reine Tonaufnahme ohne Textfassung. Wer nicht oder schlecht hört, erfährt weder den Titel des Hörbuchs noch, wo es steht (Regal H 3) und wie lange man es ausleihen kann. Die Überschrift „Hörtipp der Woche“ kennzeichnet die Aufnahme nur – das genügt für 1.1.1, nicht für 1.2.1.
• Beispiel B – erfüllt. Dieselbe Aufnahme mit Transkript direkt darunter: alles Gesprochene, wer spricht, und die Erkennungsmelodie als Geräusch (Technik G158). Vergleiche Wort für Wort – ein Transkript, das zusammenfasst oder Teile auslässt, wäre keine gleichwertige Alternative.
• Beispiel C – erfüllt. Das Video hat keine Tonspur. Die Liste darunter beschreibt alle vier Schritte so, dass man die Rückgabe auch ohne das Bild schafft (G159). Der zweite zulässige Weg wäre eine Tonspur, die das Gezeigte beschreibt (G166).
• Beispiel D – nicht erfüllt. Dasselbe stumme Video ohne Text und ohne Tonspur. Der Screenreader meldet einen Videoplayer und die Überschrift, aber keinen der vier Schritte. Die eingeblendeten Schrittzeilen im Video sind Pixel, kein Text. Blinde Nutzende erfahren nicht, wie die Rückgabe geht.
• Beispiel E – erfüllt (Ausnahme). Die Aufnahme ist selbst eine Alternative: Sie liest genau den Text vor, der darüber steht, und ist so gekennzeichnet. Dann braucht sie kein eigenes Transkript. Die Ausnahme gilt nur, wenn die Aufnahme nicht mehr Information enthält als der Text – nenne sie im Bericht und prüfe das durch Anhören.

Automatisch erkennbar? Nein. axe meldet zu den beiden Videos nur einen Punkt „von Hand zu prüfen“ (video-caption), zu den Audiodateien nichts. Ob es eine Textfassung gibt und ob sie stimmt, sieht kein Werkzeug.

Grenzfall: Ein stummes Hintergrundvideo im Kopfbereich, das nur Stimmung erzeugt, trägt keine Information: keine Alternative nach 1.2.1, es gilt als Dekoration im Sinn von 1.1.1. Läuft es länger als 5 Sekunden, muss es sich aber anhalten lassen (2.2.2). Gegenfall: Ein stummes Video, das zeigt, wie man etwas bedient – wie hier –, ist Information.

Verwandte Kriterien: 1.2.1 gilt nur für Medien, die ausschließlich Ton oder ausschließlich Bild haben. Video mit Ton fällt unter 1.2.2, 1.2.3 und 1.2.5. Die Player selbst müssen mit der Tastatur bedienbar sein (2.1.1); Ton, der von selbst startet, wäre ein Fall für 1.4.2.

• Beispiel A – erfüllt. Die Untertitel geben alles Gesprochene wieder, laufen synchron, nennen bei jedem Wechsel, wer spricht („Jana Winter:“, „Tom Berger:“), und enthalten das Geräusch, auf das sich der Dialog bezieht: „[Gong ertönt]“ bei 0:21. Die Namen sind nötig, weil zwischen 0:15 und 0:33 niemand im Bild ist. Die Spur ist zuschaltbar (Technik G87); eingebrannte Untertitel wären ebenso zulässig (G93).
• Beispiel B – nicht erfüllt. Dasselbe Video mit einer Spur, wie sie eine ungeprüfte automatische Erkennung liefert. Lösungsschlüssel zum Untertitel-Check:
  • Nicht synchron: Alle Untertitel kommen rund 2 Sekunden zu spät. Der erste Satz fällt bei 0:03, zu lesen ist er ab 0:05.
  • Nicht vollständig: Der Schlusssatz „Wir freuen uns auf euch!“ (0:34) fehlt ganz.
  • Geräusch fehlt: Der Gong bei 0:21 steht nicht da. Ohne ihn ergibt „hört ihr das“ keinen Sinn (Failure F8).
  • Sprecher nicht erkennbar: Kein Hinweis auf Sprecherwechsel; die Zeilen laufen über die Wechsel hinweg („wo das seht ihr hier hört ihr“, ab 0:17).
  • Erkennungsfehler: „lindau“ statt „Lindenau“ (0:05), „gruß geschichten“ statt „Gruselgeschichten“ (0:10), „kong“ statt „Gong“ (0:25), „meldet auch“ statt „Meldet euch“ (0:28). Dazu keine Satzzeichen, keine Großschreibung.
  Wer nicht hört, bekommt den Ortsnamen falsch, das Programm entstellt und weiß nicht, worauf sich die Frage nach dem Gong bezieht.

Automatisch erkennbar? Nein. axe meldet zu beiden Videos nichts: Die Regel video-caption schaut nur, ob es ein track-Element mit kind="captions" gibt – und das haben beide. Fehlt es, erscheint das Video unter „von Hand zu prüfen“ (siehe 1.2.4, Beispiel B). Ob die Untertitel stimmen, liest kein Werkzeug.

Grenzfall: Automatische Untertitel erfüllen 1.2.2 nur, wenn sie redaktionell geprüft und korrigiert sind. Ist das Video über einen fremden Player eingebettet, der Untertitel könnte, aber keine zeigt, bleibt es nicht erfüllt: Verantwortlich ist, wer das Video auf der eigenen Seite anbietet. Keine Untertitel braucht ein Video, das selbst eine gekennzeichnete Alternative zu einem Text auf der Seite ist und nicht mehr enthält als dieser (sonst F74, F75).

Verwandte Kriterien: Untertitel sind für Menschen, die den Ton nicht hören. Für Menschen, die das Bild nicht sehen, gelten 1.2.3 und 1.2.5 – deshalb führt unter beiden Videos ein Link zur Fassung mit Audiodeskription. Live-Videos: 1.2.4. Reines Audio oder stummes Video: 1.2.1. Die Bedienung des Players prüfst du mit 2.1.1 und 4.1.2.

• Beispiel A – nicht erfüllt. Nur im Bild, nie im Ton: Datum, Uhrzeit und Raum (0:15), Anmeldefrist, Telefonnummer und „Eintritt frei“ (0:27), dazu Namen und Funktionen der beiden Sprechenden. Jana Winter sagt sogar „Das seht ihr hier“. Wer das Bild nicht sieht, weiß am Ende, dass es eine Lesenacht gibt – aber nicht, wann, wo und wie man sich anmeldet. Es gibt weder Audiodeskription noch Textfassung. Die Untertitel helfen hier nicht: Sie geben den Ton wieder, nicht das Bild. Verletzt außerdem 1.2.5.
• Beispiel B – erfüllt (Stufe A). Unter dem Video steht eine Medienalternative: ein Volltext, der in der Reihenfolge des Videos sagt, was zu sehen und was zu hören ist, einschließlich aller eingeblendeten Angaben. Das genügt für 1.2.3. Für 1.2.5 auf Stufe AA genügt es nicht – dort ist dieses Beispiel nicht erfüllt. Im Bericht: 1.2.3 erfüllt, 1.2.5 nicht erfüllt.

Der zweite Weg, 1.2.3 zu erfüllen, ist die Audiodeskription. Die Fassung dazu steht bei 1.2.5, Beispiel B; sie erfüllt beide Kriterien.

Automatisch erkennbar? Nein. axe meldet zu beiden Videos nichts. Kein Werkzeug weiß, was im Bild zu sehen ist und ob es im Ton vorkommt.

Stolperstelle: Transkript ist nicht gleich Medienalternative. Transkript = was gesagt wird. Medienalternative = was gesagt und gezeigt wird.

Grenzfall: Spricht nur eine Person frontal in die Kamera und wird nichts eingeblendet, enthält das Bild nichts, was im Ton fehlt – dann ist weder Audiodeskription noch Textfassung nötig (siehe 1.2.5, Beispiel C). Sobald Name, Funktion oder eine Telefonnummer eingeblendet und nicht gesagt werden, fehlt Information im Ton.

Verwandte Kriterien: 1.2.5 (AA) verlangt die Audiodeskription ohne Ausweg über den Text. 1.2.2 betrifft die Gegenrichtung: Ton für Menschen, die nicht hören. Stumme Videos fallen unter 1.2.1.

• Beispiel A – erfüllt (in der Simulation). Die Untertitel laufen von selbst mit, geben alles Gesprochene wieder, nennen die Sprechenden und den Gong. Sie kommen rund anderthalb Sekunden nach dem Ton – bei Live-Untertiteln ist eine kurze Verzögerung unvermeidlich und kein Verstoß, solange man dem Geschehen folgen kann.
• Beispiel B – nicht erfüllt. Dieselbe Übertragung ohne Untertitel. Wer nicht hört, sieht zwei Menschen, zwei Tafeln und einen Gong, erfährt aber nichts von dem, was gesagt wird – und kann bei einer Live-Sendung auch nicht auf später warten.

So prüfst du echte Live-Untertitel: Nur als Stichprobe während einer Sendung. Achte auf Vollständigkeit, Verzögerung, Namen und Fachwörter, mehrere Sprechende. Untertitel von Schriftdolmetschenden (Technik G9) sind der verlässliche Weg; rein automatische Live-Untertitel sind in der Fachwelt umstritten, weil sie gerade bei Namen, Fachsprache und Sprecherwechseln Fehler machen. Bewertet wird, was in der Stichprobe ankommt. Lässt sich keine Sendung beobachten, steht im Bericht „nicht prüfbar“ mit der Auskunft des Anbieters, nicht „erfüllt“.

Automatisch erkennbar? Nein. axe führt Beispiel B unter „von Hand zu prüfen“ (video-caption), weil dem Video ein track-Element fehlt; zu Beispiel A meldet es nichts. Das ist ein Hinweis, kein Urteil: Bei echten Übertragungen kommen die Untertitel oft gar nicht über ein track-Element, sondern aus dem Player oder als eigener Textbereich neben dem Video.

Grenzfall: Bleibt die Sendung nach dem Ende als Mitschnitt auf der Seite, ist sie ab diesem Moment aufgezeichnet. Dann gelten 1.2.2, 1.2.3 und 1.2.5: Die Live-Untertitel können als Grundlage dienen, müssen aber korrigiert und synchronisiert werden. Zweiter Grenzfall: Lädt die Website nur zu einer Videokonferenz ein, prüfst du nicht die Website, sondern die Konferenzsoftware.

Verwandte Kriterien: Reiner Live-Ton ohne Bild, etwa ein Radiostream, ist erst auf Stufe AAA geregelt (1.2.9) und gehört nicht zum Prüfumfang. Eine Audiodeskription wird für Live-Videos auf A und AA nicht verlangt. Die Kennzeichnung „Live“ steht hier als Text neben dem Player; stünde sie nur im Videobild, wäre das eine Frage für 1.1.1.

• Beispiel A – nicht erfüllt. Datum, Uhrzeit, Raum, Anmeldefrist, Telefonnummer und die Namen stehen nur im Bild. Der Link führt zu einer vollständigen Textfassung – das erfüllt 1.2.3 auf Stufe A, aber nicht 1.2.5: Auf AA muss die Bildinformation zu hören sein. Wer das Video hört, soll es als Video erleben können und nicht auf einen Text ausweichen müssen.
• Beispiel B – erfüllt. Eine eigene Fassung des Videos, in der eine dritte Stimme das Gezeigte beschreibt: den Titel, wer zu sehen ist, die Einblendungen der Namen und beide Tafeln mit allen Angaben. Weil die Pausen im Original dafür zu kurz sind, bleibt das Bild an diesen Stellen länger stehen – deshalb 62 statt 37 Sekunden. Zulässig sind eine eigene Fassung mit Beschreibung (Technik G173), eine zweite, zuschaltbare Tonspur (G78) oder eine Fassung mit angehaltenem Bild (G8). Die Untertitel dieser Fassung enthalten auch die Beschreibung, damit 1.2.2 erfüllt bleibt.
• Beispiel C – erfüllt, ohne Audiodeskription. Eine Person spricht frontal in die Kamera, nichts wird eingeblendet, und sie nennt ihren Namen selbst. Das Bild enthält nichts Wichtiges, was im Ton fehlt – es gibt nichts zu beschreiben. Dieselbe Aufnahme mit eingeblendeten, aber nicht gesprochenen Öffnungszeiten wäre nicht erfüllt.

Automatisch erkennbar? Nein. axe meldet zu keinem der drei Videos etwas. Ob das Bild etwas zeigt, das im Ton fehlt, und ob eine Beschreibung es wiedergibt, hört nur ein Mensch.

Für die Praxis: Am einfachsten ist die Beschreibung im Hauptton. Sagt Jana Winter statt „Das seht ihr hier“ gleich „Freitag, 13. November, 19 Uhr, Raum 2.14“ und werden ebenso die Angaben der zweiten Tafel (Anmeldefrist, Telefonnummer, Eintritt frei) und die beiden Namen gesagt, braucht das Video keine zweite Fassung, und 1.2.3 ist mit erfüllt. Das ist eine Frage des Drehbuchs, nicht der Filmproduktion.

Grenzfall: Der Mitschnitt eines Webinars, in dem Folien gezeigt, aber nicht vorgelesen werden („wie ihr hier seht …“), ist ein typischer Verstoß. Ein Mitschnitt fällt nicht mehr unter 1.2.4, sondern unter die Kriterien für aufgezeichnete Medien.

Verwandte Kriterien: 1.2.3 (A) lässt die Wahl zwischen Audiodeskription und Textfassung; 1.2.5 (AA) nimmt die Textfassung als Ausweg weg. Wer nach AA prüft, bewertet beide: Beispiel A hier ist bei 1.2.3 erfüllt und bei 1.2.5 nicht. Stumme Videos: 1.2.1.

• Beispiel A – nicht erfüllt. „Ausweis verlängern“, „Online“ und „Vor Ort“ sehen aus wie Überschriften, sind aber ein div und Absätze mit großer oder fetter Schrift. Im Baum fehlt die Rolle „heading“, in der Gliederung von HeadingsMap oder WAVE fehlen die drei Einträge, und mit H springt der Screenreader an den drei Zeilen vorbei. Wer nicht sieht, erkennt die Gliederung nicht und kann die Abschnitte nicht gezielt ansteuern.
• Beispiel B – erfüllt. Dieselbe Darstellung, aber mit h5 und h6. Die Ebenen bilden ab, was man sieht: „Online“ und „Vor Ort“ sind Unterabschnitte von „Ausweis verlängern“.
• Beispiel C – nicht erfüllt. Hier ist alles als Überschrift ausgezeichnet – auch der Spruch „Geschichten machen groß.“ (h5), der nur wegen der großen Schrift ein Überschriften-Element bekommen hat. Unter ihm beginnt kein Abschnitt. In der Gliederung hängen „Termine“ und „Anmeldung“ jetzt unter dem Spruch statt unter „Vorlesestunde für Kinder“: Die Auszeichnung behauptet eine Beziehung, die es im Inhalt nicht gibt. Diese Bühne verbiegt die Gliederung der Übungsseite an dieser Stelle absichtlich.
• Beispiel D – erfüllt. ul und ol. Der Screenreader sagt „Liste mit 3 Einträgen“ an, L springt hin. Die Gedankenstriche kommen aus dem CSS und sind reine Gestaltung.
• Beispiel E – nicht erfüllt. Striche und Ziffern sind getippt, die Zeilen mit br umbrochen. Für den Screenreader ist das je ein Absatz Fließtext: keine Ansage „Liste“, keine Anzahl der Einträge, kein Sprung mit L. Ohne Stile sieht es fast gleich aus – verräterisch ist erst der Code oder der Baum.
• Beispiel F, Seite 1 – nicht erfüllt. Die fünf Bereiche sind nur gestaltet: lauter div, keine Landmarks, und auch „Willkommen …“, „Aktuelles“ und „Öffnungszeiten“ sind keine Überschriften. Mit D und H findet der Screenreader nichts; der Rotor von VoiceOver zeigt weder Orientierungspunkte noch Überschriften. Der Sprunglink am Anfang funktioniert – 2.4.1 ist deshalb nicht betroffen.
• Beispiel F, Seite 2 – erfüllt. header, nav mit Namen, main, aside mit Namen, footer, dazu h1 und h2. Jeder sichtbare Bereich ist als Landmark ansteuerbar.
• Beispiel F, Seite 3 – Grenzfall, umstritten. Keine Landmarks, aber echte Überschriften für den Hauptinhalt und die Randspalte. Landmarks sind eine ausreichende Technik, nicht die einzige; sind die Inhaltsbereiche über Überschriften erkennbar, bewerten viele Prüfende 1.3.1 als erfüllt. Kopf, Navigation und Fuß bleiben hier allerdings unbenannt. Im Bericht: als Empfehlung notieren, mit Blick auf 2.4.1.
• Beispiel G – Grenzfall, in der Regel kein Verstoß. Ein einziges div, die Absätze entstehen durch doppelte br. Die Beziehung „neuer Absatz“ trägt hier keine Bedeutung, die verloren ginge; Screenreader lesen den Text verständlich vor, verloren geht höchstens das Springen von Absatz zu Absatz. Nach den WCAG: als Hinweis notieren, nicht als Verstoß. Der BITV-Test ist hier strenger: Im Prüfschritt 9.1.3.1d „Inhalt gegliedert“ führen doppelte br für Textabsätze zu „nicht voll erfüllt“, weil im Lesemodus der Screenreader leere Positionen entstehen können. Wer nach dem BITV-Test prüft, bewertet Beispiel G also als Mangel.
• Beispiel H – erfüllt. Drei p-Elemente.
• Beispiel I – erfüllt. Die Information steht im Text („ausgebucht“) und ist zusätzlich mit strong hervorgehoben. Wer die Schrift nicht sieht, erfährt dasselbe.
• Beispiel J – nicht erfüllt. „Ausgebucht“ steckt allein in der Schriftstärke, und die kommt nur aus dem CSS (span mit Klasse). Weder Code noch Text tragen die Information; der Screenreader liest vier gleichwertige Termine vor. Auch strong allein wäre hier zu wenig, denn Screenreader sagen Hervorhebungen in der Grundeinstellung meist nicht an – der Text muss es sagen, wie in Beispiel I.

Automatisch erkennbar? Kaum. axe meldet zu keinem der Beispiele A bis J einen Verstoß – ein Werkzeug sieht, ob Markup vorhanden ist, aber nicht, ob es zur Darstellung passt. WAVE zeigt die Gliederung und kann große oder fette Kurzabsätze als „Possible heading“ markieren; das ist ein Hinweis zum Nachprüfen, kein Urteil. Auf Seite 1 und Seite 3 zu Beispiel F meldet axe nur mit eingeschalteten „Best Practices“ etwas zu fehlenden Landmarks.

Grenzfall übersprungene Ebene: Folgt auf eine h2 direkt eine h4, ist das für sich kein Verstoß – die WCAG verlangen keine lückenlose Hierarchie. WAVE zeigt dafür eine Warnung („Skipped heading level“), keinen Fehler. Ein Verstoß ist es erst, wenn die Ebenen die Beziehung verkehrt darstellen – etwa ein Unterabschnitt auf höherer Ebene als sein Abschnitt oder, wie in Beispiel C, eine Überschrift, die gar keinen Abschnitt einleitet.

Grenzfall Betonung: Reines Betonen ohne Bedeutungsänderung („Bitte komm pünktlich“) ist kein Fall für 1.3.1, egal wie es ausgezeichnet ist. Kritisch wird es, wenn an der Hervorhebung eine Information hängt, die sonst nirgends steht.

Verwandte Kriterien: Ob eine Überschrift beschreibt, was folgt, ist 2.4.6 – hier geht es nur darum, ob sie als Überschrift ausgezeichnet ist. Ob sich wiederholende Blöcke umgehen lassen, ist 2.4.1. Information nur über Farbe ist 1.4.1.

• Beispiel K, Tabelle 1 – nicht erfüllt. Eine Datentabelle: Jede Uhrzeit gehört zu einer Linie und einer Richtung. Die Kopfzeile besteht aber aus gewöhnlichen td, die nur fett und farbig gestaltet sind. Im Baum haben „Linie“, „Richtung“ und „Abfahrt“ die Rolle „cell“ statt „columnheader“; beim Wechsel der Zelle sagt der Screenreader nur „14:16 Uhr“ an, ohne „Abfahrt“. Korrektur: Kopfzeile mit th scope="col".
• Beispiel L, Tabelle 2 – nicht erfüllt. Eine Layouttabelle: Sie ordnet nur an, links die Navigation, rechts der Inhalt. Trotzdem trägt sie Auszeichnung einer Datentabelle – eine (unsichtbar gemachte) caption „Layout“ und ein th scope="col" für „Service“. Der Screenreader sagt sinngemäß „Tabelle Layout, 2 Zeilen, 2 Spalten“ an und liest „Service“ als Spaltenkopf zu den Links. Korrektur: Layout mit CSS; wenn die Tabelle bleibt, dann ohne th und caption und mit role="presentation". Verletzt außerdem 1.3.2: Zeile für Zeile gelesen kommt „Service – Neu im Regal – Über 200 neue Romane … – Ausleihe, Termine, Kontakt“; der Titel der Navigation ist durch den ganzen Inhaltsblock von seinen Links getrennt (Layouttabelle, die linear gelesen keinen Sinn ergibt). Die Überschrift „Neu im Regal“ und die Linkliste selbst sind in Ordnung.
• Beispiel M, Tabelle 3 – erfüllt. Mehrstufig, aber vollständig ausgezeichnet: je Wochentag eine colgroup span="2", die Wochentage als th colspan="2" scope="colgroup", „Vormittag“ und „Nachmittag“ als th scope="col", die Standorte als th scope="row". Lernpunkt: Komplex heißt nicht verletzt. Wie viel davon angesagt wird, unterscheidet sich je Screenreader und Browser – nicht jede Kombination nennt beide Ebenen, also Wochentag und Tageszeit. Robuster, aber aufwendiger, ist die Zuordnung mit headers und id.
• Beispiel N, Station 4 – nicht erfüllt. „Ja“ und „Nein“ sind richtig beschriftet, aber die Frage „Rückruf erwünscht?“ ist nur ein Absatz davor. Wer mit der Tabulatortaste in die Gruppe springt, hört sinngemäß „Ja, Auswahlschalter, nicht aktiviert, 1 von 2“ – wozu, bleibt offen. Die sichtbare Zusammengehörigkeit von Frage und Optionen steht nicht im Code. Korrektur: fieldset und legend wie in Beispiel O.
• Beispiel O – erfüllt. fieldset mit legend. Beim Sprung in die Gruppe wird die Frage mit angesagt, sinngemäß „Erinnerung per E-Mail?, Gruppierung“. Im Baum: Rolle „group“ mit dem Namen aus der legend. Gleichwertig wäre role="radiogroup" mit aria-labelledby.
• Beispiel P – nicht erfüllt. Die Sternchen sind zu sehen, kommen bei Hilfsmitteln aber nicht an: Sie stehen in einem span mit aria-hidden="true", und die Felder tragen weder required noch aria-required. Im Baum heißt das Feld nur „Name“, der Screenreader sagt nichts von „erforderlich“. Die sichtbare Information „Pflichtfeld“ ist weder im Code ermittelbar noch im Text gesagt. Außerdem fehlt die Erklärung, was das Sternchen bedeutet (siehe Streitfall).
• Beispiel Q – erfüllt für 1.3.1; Streitfall bei 3.3.2. Das Sternchen ist Text im label, und die Felder tragen required; im Baum heißt das Feld „Name *“ mit dem Zustand „erforderlich“. Die Information kommt im Code an. Nirgends steht aber, was das Sternchen bedeutet.
• Beispiel R – Grenzfall, kein sicherer Verstoß. Die Sternchen stehen nicht im HTML, sondern kommen per CSS (::after mit content); required fehlt. Früher galt das als Verstoß gegen 1.3.1 (Failure F87). Das W3C führt F87 inzwischen als überholt: Heutige Browser übernehmen CSS-generierten Text in den zugänglichen Namen – im Baum heißt das Feld „Name *“, genau wie in Q. Es bleiben Nachteile: Ohne Stile oder mit eigener Stilvorlage sind die Sternchen weg, sie lassen sich nicht markieren und nicht mit der Seitensuche finden. Im Bericht: Empfehlung „Sternchen ins HTML und required setzen“, kein Verstoß. Der Unterschied zu P: Dort ist das Sternchen für Hilfsmittel ausdrücklich versteckt.

Streitfall Sternchen – 1.3.1 oder 3.3.2? Es kommt auf die Umsetzung an, denn es sind zwei Fragen. 1.3.1 fragt, ob die Information „Pflichtfeld“ im Code ankommt: in Q ja (Text im label und required), in P nein, in R nach heutigem Stand ebenfalls ja – nur weniger robust. 3.3.2 fragt, ob verständlich angeleitet wird: Fehlt die Erklärung „Felder mit * sind Pflichtfelder“, fehlt eine Anweisung. Weil die Konvention verbreitet ist, wird das in der Prüfpraxis unterschiedlich streng bewertet. Empfehlung für den Bericht: 3.3.2 als nicht voll erfüllt mit geringer Schwere, dazu der Vorschlag, die Erklärung an den Formularanfang zu setzen und required zu verwenden. Das gilt für alle drei Formulare. Wäre das Sternchen ein Bild ohne Alternativtext, ginge es um 1.1.1.

Automatisch erkennbar? Nein. axe meldet zu keinem der Beispiele K bis R einen Verstoß: Fehlende Kopfzellen, eine Layouttabelle mit th, eine Optionsgruppe ohne Gruppierung und versteckte Sternchen erkennt nur, wer hinsieht, hinhört und in den Code schaut.

Grenzfall: Bei einer einfachen Tabelle mit einer Kopfzeile genügt th; scope macht die Richtung eindeutig und ist gute Praxis. Eine caption ist ebenfalls gute Praxis, aber nicht von 1.3.1 verlangt – Tabelle 1 scheitert an den Kopfzellen, nicht an der Beschriftung.

Verwandte Kriterien: Ob ein Feld überhaupt eine sichtbare Beschriftung hat, ist 3.3.2; ob sie im zugänglichen Namen ankommt, 4.1.2. Ob eine Layouttabelle in sinnvoller Reihenfolge vorgelesen wird, ist 1.3.2.

• Beispiel A – erfüllt. Die drei Schritte stehen im DOM in derselben Reihenfolge, in der du sie siehst: 1, 2, 3.
• Beispiel B – nicht erfüllt. Sieht genauso aus wie A, aber im DOM steht Schritt 2 vor Schritt 3 vor Schritt 1. Erst die CSS-Eigenschaft order sortiert die Kästen auf dem Bildschirm um. Der Screenreader liest „Schritt 2: Auswählen – Wähle dort …“, bevor überhaupt vom Anmelden die Rede war; auch die Überschriftenliste zeigt 2, 3, 1. Bei einer Anleitung trägt die Reihenfolge die Bedeutung – hier ändert die Positionierung per CSS den Sinn. Betroffen sind alle, die linear lesen: Screenreader, Braillezeile, Lesemodus, eigene Stilvorlagen.
• Beispiel C – nicht erfüllt, wegen der fehlenden Gruppierung. Auf dem Bildschirm steht der Preis unter dem Produkt. Im DOM steht er davor – und die Karten sind nur div, also für Hilfsmittel nicht als Einheiten erkennbar. Erst beides zusammen entstellt den Sinn. Vorgelesen ergibt das: „4,00 € – Lesetasche – Aus Baumwolle … – 18,00 € – Jahresausweis …“. Wer von Überschrift zu Überschrift geht und weiterliest, hört nach „Lesetasche“ als nächsten Preis 18,00 €: Der Preis rutscht zum vorigen Produkt, und der erste Preis hängt in der Luft.
• Beispiel D – erfüllt. Auch hier weicht das DOM von der Darstellung ab: Der Kasten „Kontakt“ steht im Code vor dem Beitrag, das Grid zeigt ihn rechts daneben (schmal: darunter). Beide Blöcke sind aber voneinander unabhängig; welcher zuerst vorgelesen wird, ändert nichts am Sinn. Nicht jede Abweichung ist ein Verstoß.

Automatisch erkennbar? Nein. axe meldet zu keinem der vier Beispiele etwas; ob eine Reihenfolge Bedeutung trägt, kann nur ein Mensch beurteilen.

Grenzfall Dialog am Ende des DOM: Viele Dialoge und Hinweise hängen im Code ganz am Ende der Seite. Öffnet sich der Dialog und der Fokus wird hineingesetzt, liest der Screenreader ihn im richtigen Moment – für 1.3.2 kein Problem. Bleibt der Fokus dagegen auf der Seite, finden Screenreader-Nutzende den Dialog erst nach dem gesamten Inhalt. Das ist in erster Linie 2.4.3; bei einem nicht modalen Hinweis, der sich auf eine bestimmte Stelle bezieht („Dieses Feld …“), aber im Code weit davon entfernt steht, auch 1.3.2.

Grenzfall schmale Ansicht: Sortiert ein Layout erst unterhalb einer bestimmten Breite um, prüfst du genau an dieser Breite. In Beispiel B bleibt die Abweichung bei jeder Breite bestehen, auch wenn die Schritte untereinander stehen.

Grenzfall Gruppierung: Wären die Karten in Beispiel C Listeneinträge (li), würde der Screenreader Anfang und Ende jeder Karte ansagen; „Preis vor Name“ innerhalb eines Eintrags wäre dann unschön, aber nicht mehr sinnentstellend.

Verwandte Kriterien: Die Reihenfolge beim Tabben ist 2.4.3, die Lesereihenfolge ist 1.3.2. Ob Struktur überhaupt ausgezeichnet ist, ist 1.3.1.

• Beispiel A – erfüllt. Die Anleitung nennt die Schaltflächen beim Namen – „Reservierung abschicken“ und „Zurück“. Farbe und Lage stehen nur zusätzlich in Klammern. Wer die Seite hört, auf einem schmalen Bildschirm sieht oder Farben nicht unterscheidet, findet die Schaltflächen über den Namen.
• Beispiel B – nicht erfüllt. „Der grüne Knopf rechts“ und „der graue Knopf links“ – die Anleitung beschreibt die Schaltflächen nur über Farbe und Lage. Die Schaltflächen selbst sind in Ordnung und heißen wie in A. Mit dem Screenreader gibt es aber weder „grün“ noch „rechts“; auf einem schmalen Bildschirm oder bei starker Vergrößerung stehen die Schaltflächen untereinander, und „rechts“ stimmt nicht mehr.
• Beispiel C – erfüllt (Grenzfall „siehe unten“). „Unten“ ist zwar eine Lageangabe, bedeutet im Deutschen aber auch „weiter hinten im Text“. Die Liste folgt in der Lesereihenfolge tatsächlich nach dem Hinweis und ist eindeutig; zusätzlich trägt sie eine Überschrift. So bewertet es auch das W3C in den Erläuterungen zu 1.3.3. Kritisch würde es, wenn die Liste im Code vor dem Hinweis stünde oder mehrere Listen folgten.
• Beispiel D – nicht erfüllt. Die Anleitung stützt sich allein auf den Ton: hoch heißt gebucht, tief heißt „zur Theke“. Wer gehörlos oder schwerhörig ist, den Ton abgestellt hat oder in lauter Umgebung arbeitet, erfährt das Ergebnis nicht. Es fehlt eine sichtbare Meldung, etwa „Verbucht“ oder „Bitte wende dich an die Theke“. Dass auch das Ergebnis selbst nur als Ton kommt, ist zusätzlich ein Fall für 1.1.1. Die Schaltfläche „Ton für Beispiel D“ und die Anzeige „Ton ist an/aus“ gehören zur Übungsseite, nicht zum Beispiel; die Töne kommen abwechselnd hoch und tief.

Automatisch erkennbar? Nein. Kein Werkzeug versteht, worauf sich eine Anleitung bezieht; axe meldet zu keinem der Beispiele etwas. Hier hilft nur Lesen.

Grenzfall: Eine sinnliche Angabe ist nicht verboten – sie darf nur nicht die einzige sein. „Wähle ‚Weiter‘ (grüner Knopf rechts)“ genügt. Ein Symbol allein („Räume mit ▲ haben einen Beamer“) reicht dagegen nicht, wenn das Symbol keine Textalternative hat.

Verwandte Kriterien: Information nur über Farbe – ohne dass eine Anleitung im Spiel ist – gehört zu 1.4.1. Stimmt der sichtbare Name einer Schaltfläche nicht mit dem zugänglichen Namen überein, ist das 2.5.3. Fehlt die Anleitung ganz, ist es 3.3.2.

• Beispiel A – nicht erfüllt. Im Querformat eines Smartphones verschwindet der Ausweis, stattdessen steht dort „Bitte drehe dein Gerät ins Hochformat“. Dahinter steckt eine CSS-Medienabfrage: @media (orientation: landscape) and (max-height: 600px) blendet den Inhalt aus und die Aufforderung ein. Für einen Ausweis mit Strichcode ist das Hochformat nicht wesentlich. Wer das Gerät fest montiert hat, zum Beispiel quer am Rollstuhl, kann nicht drehen und kommt nicht an den Ausweis. Die Sperre greift nur bis 600 CSS-Pixel Höhe: Auf einem Tablet im Querformat bleibt alles sichtbar – wer nur mit einem Tablet-Profil prüft, findet nichts. Verletzt außerdem 1.4.4 und 1.4.10: Am Rechner verschwindet der Inhalt ebenfalls, sobald das Fenster durch Zoomen oder Verkleinern breiter als hoch und höchstens 600 CSS-Pixel hoch ist.
• Beispiel B – erfüllt. Derselbe Ausweis, ohne Sperre. Im Querformat rücken Ausweis und Ausleihliste nebeneinander; alles bleibt lesbar und bedienbar.
• Beispiel C – erfüllt (Ausnahme). Die Klaviatur verlangt auf schmalen Geräten das Querformat und zeigt im Hochformat eine Aufforderung zum Drehen – genau das, was in A ein Verstoß ist. Hier greift die Ausnahme: Zwei Oktaven mit 25 Tasten passen hochkant auf kein Smartphone, ohne dass die Tasten zu schmal zum Treffen werden (bei 360 bis 414 CSS-Pixel Breite blieben für eine weiße Taste nur rund 19 bis 23 Pixel, für eine schwarze 14 bis 16). Das W3C nennt eine Klavier-Anwendung ausdrücklich als Beispiel für „wesentlich“. Die Seite sperrt deshalb nur Hochformat-Ansichten, in die die Klaviatur mit ihrer Mindestbreite nicht hineinpasst (Medienabfrage (orientation: portrait) and (max-width: 32.75rem), also bis 524 CSS-Pixel bei üblicher Schriftgröße); auf einem Tablet hochkant bleibt die Klaviatur spielbar. Überschrift, Erklärung und der Link zurück bleiben immer sichtbar. Die Ausnahme ist eine Abwägung: Je weniger Tasten, desto schwächer das Argument – eine einzige Oktave hätte auch hochkant Platz, und die Sperre wäre dann ein Verstoß. Zwei Einwände solltest du kennen: Die Sperre trifft auch ein schmales, hohes Fenster am Rechner, wo niemand drehen kann. Und seitliches Verschieben wäre hochkant technisch möglich – die Seite nutzt es selbst in sehr schmalen Querformat-Fenstern. Ob eine Klaviatur, von der man nur die Hälfte sieht, noch dieselbe Funktion ist, ist die Streitfrage; am Urteil ändert sie nichts.

Automatisch erkennbar? Im Wesentlichen nein. axe meldet auf keiner der drei Seiten etwas dazu; du musst drehen und hinsehen. Verdächtig sind im Code orientation in Medienabfragen, transform: rotate(90deg) auf dem ganzen Inhalt und screen.orientation.lock() im Skript.

Grenzfall: Ein Modul, das einen Überweisungsträger oder Scheck im Querformat abfotografiert, kann wesentlich sein; eine Nachrichtenseite oder ein Formular nie. Kein Befund ist es, wenn das Gerät der prüfenden Person selbst gesperrt ist – deshalb zuerst die Ausrichtungssperre lösen. Kein Befund für 1.3.4 ist es auch, wenn eine Seite im Querformat zwar anders umbricht, aber vollständig bleibt.

Verwandte Kriterien: Ob Inhalte bei 320 CSS-Pixel Breite ohne Querscrollen auskommen, ist 1.4.10. Funktionen, die durch Bewegen oder Kippen des Geräts ausgelöst werden, gehören zu 2.5.4.

• Beispiel A – nicht erfüllt. Von sieben Feldern über die nutzende Person tragen nur drei den passenden Wert. Dazu kommt ein Wert an einem Feld, das gar keinen braucht. Die Einzelheiten stehen in der Tabelle.
• Beispiel B – erfüllt. Alle sieben Felder unter „Deine Angaben“ tragen den passenden Wert. Die Felder unter „Für wen ist der Ausweis?“ betreffen eine andere Person und tragen zu Recht keinen.

Wozu das Ganze? Browser, Passwortmanager und Hilfsmittel können solche Felder ausfüllen oder mit vertrauten Symbolen kennzeichnen. Das hilft Menschen, die wenig tippen können, und Menschen, denen es schwerfällt, sich Daten zu merken oder fehlerfrei abzuschreiben.

Automatisch erkennbar? Teilweise. axe meldet in Beispiel A genau eine Stelle: den ungültigen Wert e-mail (Regel „autocomplete-valid“). Den fehlenden Wert am Nachnamen, das off am Telefon, den gültigen, aber unpassenden Wert am Ort und den überflüssigen Wert beim Namen der beschenkten Person meldet axe nicht. In Beispiel B meldet axe nichts.

Grenzfall: Die Lieferanschrift einer Geschenkbestellung kann die eigene sein; dafür gibt es die Abschnittskennung shipping vor dem Wert, etwa shipping address-line1. Für die Straße gibt es zwei Werte: address-line1 für ein einzeiliges Feld wie hier und street-address für ein mehrzeiliges Feld (textarea); an einem einzeiligen input passt street-address laut HTML-Standard nicht, auch wenn axe es durchlässt. Suchfeld, Gutscheincode und Nachrichtentext haben keinen Zweck aus der Liste – dort ist 1.3.5 nicht anwendbar. Ein Formular, in dem Mitarbeitende die Daten von Kundschaft erfassen, fragt nicht nach Daten über die nutzende Person.

Verwandte Kriterien: Ob das Feld eine verknüpfte Beschriftung hat, ist 1.3.1 und 4.1.2. Dass bereits eingegebene Daten in einem Prozess nicht noch einmal abgefragt werden, ist 3.3.7. autocomplete für Benutzername und Passwort hilft auch bei 3.3.8.

• Beispiel A – nicht erfüllt. Die Links sind nicht unterstrichen und unterscheiden sich vom Fließtext nur durch die Farbe: Linkfarbe #0000EE gegen Textfarbe #000000 ergibt 2,23:1 – unter den 3:1, mit denen sich ein Link noch über den Helligkeitsunterschied erkennen ließe. Die Unterstreichung erscheint erst, wenn die Maus schon darüber ist; wer die Links nicht findet, fährt auch nicht darüber (Fehlerbild F73). Betroffen sind Menschen, die Farben nicht oder anders unterscheiden, und alle bei Graustufen-Anzeige. Du merkst es in Graustufen: Die Links verschwinden im Text.
• Beispiel B – erfüllt. Dieselben Farben, aber die Links sind unterstrichen. Die Unterstreichung ist der zweite Hinweis; die Farbe darf dann beliebig nah an der Textfarbe liegen.
• Beispiel C – erfüllt (Grenzfall). Keine Unterstreichung, aber die Linkfarbe #C2185B hat zur Textfarbe #000000 3,58:1. Damit unterscheidet sich der Link nicht nur im Farbton, sondern auch in der Helligkeit – das ist der übliche Nachweis über mindestens 3:1 zwischen Link und umgebendem Text (Technik G183). Bei Hover und Fokus kommt hier zusätzlich eine Unterstreichung dazu; das ist eine Empfehlung, das Urteil hängt an der Messung. Zum weißen Hintergrund hat die Linkfarbe 5,87:1, 1.4.3 ist also ebenfalls erfüllt. Hinweis: Manche Prüfstellen bewerten Links im Fließtext ohne Unterstreichung strenger.
• Beispiel D – erfüllt. Jede Linie hat neben der Farbe ein eigenes Strichmuster und eine eigene Markerform (Kreis, Quadrat, Dreieck); die Legende zeigt dieselben Muster (Farbe plus Muster, Technik G111). In Graustufen bleibt die Zuordnung eindeutig. Noch besser lesbar wäre eine Beschriftung direkt an den Linien.
• Beispiel E – nicht erfüllt. Die drei Linien unterscheiden sich nur in der Farbe (#C62828, #2E7D32, #A65E00), die Legende ordnet nur über Farbfelder zu. Die Farben sind fast gleich hell (zum Weiß 5,62:1, 5,13:1 und 4,97:1) – in Graustufen und bei Rot-Grün-Sehschwäche lässt sich nicht mehr sagen, welche Linie die Hörbücher zeigt. Der Kontrast der Linien zum Hintergrund reicht aus; 1.4.11 ist nicht das Problem.
• Beispiel F – nicht erfüllt. Pflichtfelder sind nur an der roten Beschriftung zu erkennen, fehlende Angaben nach dem Absenden nur am roten Rahmen; die Meldung verweist ebenfalls nur auf die Farbe. Die rote Beschriftung (#7A1712) hat zur normalen Beschriftung (#16233A) nur 1,47:1, der rote Rahmen (#B3261E) zum normalen Rahmen (#5B6577) nur 1,11:1 – in Graustufen sehen alle Felder fast gleich aus. Wer Rot nicht von Dunkelblau und Grau unterscheidet, findet weder die Pflichtfelder noch die Lücken. Im Code sind die Felder mit required und nach dem Absenden mit aria-invalid="true" gekennzeichnet – ein Screenreader sagt es also an, sichtbar ist es trotzdem nur über Farbe. Das ist das Fehlerbild F81. Dazu kommt 3.3.1: Welches Feld betroffen ist und was fehlt, steht nirgends als Text.
• Beispiel G – erfüllt. Pflichtfelder tragen den Zusatz „(Pflichtfeld)“ in der Beschriftung. Nach dem Absenden nennt die Meldung die fehlenden Felder beim Namen, und unter jedem Feld steht ein Text mit Warnzeichen. Der rote Rahmen kommt nur dazu.
• Beispiel H – erfüllt. Die gewählte Sortierung ist rot, aber zusätzlich fett und mit einem dicken Balken unterstrichen. Form und Schriftstärke bleiben in Graustufen erkennbar. Im Code steht der Zustand als aria-pressed="true". Für eine Auswahl, bei der immer genau eine Möglichkeit gilt, wären Optionsfelder die genauere Auszeichnung; für die Frage hier spielt das keine Rolle.
• Beispiel I – nicht erfüllt. Die gewählte Sortierung unterscheidet sich nur in der Farbe: Schrift #B3261E statt #4A5361 (zueinander 1,19:1), Rand #B3261E statt #5B6577 (1,11:1). In Graustufen ist nicht zu sehen, welche Schaltfläche gedrückt ist. Ein Screenreader sagt es an (aria-pressed), 4.1.2 ist also erfüllt – sichtbar ist der Zustand trotzdem nur über Farbe. Antwort auf die Zusatzstufe: Das ist 1.4.1. 1.4.11 ist hier nicht verletzt, denn es verlangt keinen Kontrast zwischen zwei Zuständen, sondern zwischen dem, was man zum Erkennen braucht, und seiner Umgebung: Rote Schrift und roter Rand haben zum Weiß 6,54:1. Beides zusammen wäre es, wenn der Zustand nur über eine Farbe gezeigt würde, die selbst weniger als 3:1 zur Umgebung hat (etwa hellgelbe Schrift auf Weiß). Der blasse Haken in Beispiel D bei 1.4.11 ist dagegen nur 1.4.11.

Abgrenzung zu 1.4.3: 1.4.1 fragt „nur Farbe?“, 1.4.3 fragt „genug Kontrast zum Hintergrund?“. Das sind zwei Messungen. In Beispiel A hat der Link zum weißen Hintergrund 9,40:1 – 1.4.3 ist erfüllt, 1.4.1 nicht. Auch die rote Beschriftung in Beispiel F (#7A1712 auf Weiß, 10,72:1) besteht 1.4.3 und scheitert trotzdem an 1.4.1.

Automatisch erkennbar? Teilweise. axe meldet Beispiel A mit der Regel link-in-text-block (Links müssen sich ohne Farbe vom umgebenden Text unterscheiden); Beispiel C lässt axe wegen der 3:1 durchgehen. Das Diagramm in Beispiel E, das Formular in Beispiel F und die Schaltflächen in Beispiel I meldet axe nicht.

Grenzfall: Links in einer Navigation oder in einer Linkliste sind nicht gemeint – dort macht die Position klar, dass es Links sind. Graustufen sind ein Suchwerkzeug, kein Urteil.

Verwandte Kriterien: 1.3.3 (Anweisungen, die sich nur auf Form, Größe oder Position stützen), 1.4.3 und 1.4.11 (Kontrast), 3.3.1 und 3.3.2 (Fehler und Pflichtangaben in Textform).

• Beispiel A – erfüllt. Die Musik startet mit dem Laden und läuft rund 24 Sekunden. Ganz am Anfang des Beispiels – vor allem anderen Inhalt – stehen die Schaltfläche „Musik anhalten“ und ein Lautstärkeregler, der nur diese Musik betrifft. Beides ist mit der Tastatur bedienbar und beschriftet. Wer mit Screenreader arbeitet, erreicht die Schaltfläche als erstes Bedienelement des Beispiels und hat danach Ruhe für die Sprachausgabe (Technik G170: Bedienelement am Anfang der Seite).
• Beispiel B – nicht erfüllt. Dieselbe Musik, dieselbe Dauer, aber im Beispiel gibt es kein Bedienelement dafür. Die Musik überdeckt die Sprachausgabe; die Lautstärke des Geräts zählt nicht als Ausweg, weil sie die Sprachausgabe mit leiser stellt. Betroffen sind auch Menschen, die Ton schwer ausblenden können. Du merkst es daran, dass du im Beispiel nichts findest, womit der Ton aufhört (Fehlerbild F23).
• Beispiel C – erfüllt. Es erklingt nur ein kurzer Dreiklang von rund 2 Sekunden. Ton, der nach höchstens 3 Sekunden von selbst endet, braucht kein Bedienelement (Technik G60).

Zur Steuerung der Übungsseite: „Beispiel A laden“ und „Beispiel A stoppen“ (ebenso für B und C) gehören nicht zum Beispiel – sie ersetzen das Neuladen einer Seite. In einer echten Seite stünde im Code etwa ein audio-Element mit autoplay oder ein Skript, das beim Laden abspielt. Hier erzeugt ein Skript die Töne (WebAudio) erst nach deinem Klick; sie sind gedämpft und enden spätestens nach 24 Sekunden.

Nicht-Beeinträchtigung: 1.4.2 gehört mit 2.1.2, 2.2.2 und 2.3.1 zu den vier Kriterien, die für jeden Inhalt einer Seite gelten – auch für Werbung, eingebettete Fremdinhalte oder Bereiche, die nicht zum Prüfumfang gehören. Ein einziger selbst startender Ton ohne Bedienelement macht die ganze Seite für manche Menschen unbenutzbar.

Stolperstelle beim Prüfen: Browser sperren selbst startenden Ton oft, je nachdem, ob du mit der Seite schon einmal etwas getan hast. Bleibt es still, ist das kein Beleg dafür, dass das Kriterium erfüllt ist: Bei anderen Menschen, in einem anderen Browser oder beim zweiten Besuch kann der Ton starten. Sieh im Code nach oder erlaube den automatischen Start für die Seite in den Website-Einstellungen des Browsers und lade neu. Halte den Ton aus dem Konferenzmikrofon heraus.

Automatisch erkennbar? Kaum. axe kennt eine Regel für audio- und video-Elemente mit autoplay (no-autoplay-audio). Ton aus einem Skript wie hier erkennt kein automatisches Werkzeug; in diesen drei Beispielen meldet axe nichts – auch nicht im geladenen Zustand.

Grenzfall: Ein stummes Hintergrundvideo, das von selbst startet, hat keinen Ton – das ist kein Fall für 1.4.2, sondern für 2.2.2. Ton, der erst nach einem Klick auf „Abspielen“ startet, ist nicht betroffen.

Verwandte Kriterien: 2.2.2 (Bewegung anhalten), 1.2.1 und 1.2.2 (Alternativen für Audio- und Videoinhalte).

Alle Verhältnisse sind nach der Formel der WCAG gerechnet – aus den Farbwerten im CSS, bei Bildern (Stelle 3, Beispiele H und I) aus den Pixeln der Bilddatei. Mit der Pipette kannst du einige Hundertstel daneben liegen; entscheidend ist, ob dein Wert die Schwelle kreuzt.

• Beispiel A, Stelle 1 – erfüllt; im Hover- und Fokuszustand des Links nicht erfüllt. Die Farbfläche sieht verdächtig aus, der Fließtext besteht aber mit 5,25:1. Liegt die Maus auf dem Link oder hat er den Fokus, wird sein Hintergrund hellgrün und die Schrift bleibt weiß: 1,63:1. Zustände gehören zur Prüfung – wer den Link mit der Tastatur ansteuert, kann ihn genau in diesem Moment nicht mehr lesen.
• Beispiel A, Stelle 2 – nicht erfüllt. Platzhaltertext ist Text und braucht 4,5:1; hier sind es 2,52:1. Der Text, den du selbst eintippst, ist dunkel genug. Stolperstelle: Die Pipette trifft leicht den Feldrahmen oder die Kantenglättung der dünnen Schrift – dann lieber den Farbwert aus dem CSS nehmen (::placeholder).
• Beispiel A, Stelle 3 – nicht erfüllt. Maßgeblich ist der Hintergrund direkt hinter den Zeichen, und zwar an der ungünstigsten Stelle: Der Anfang beider Zeilen steht über dem hellen Fenster (1,33:1). Dass der Rest über dem dunklen Regal gut lesbar ist, rettet den Text nicht. Die Entwicklerwerkzeuge zeigen hier keinen Wert an – das ist die Grenze des Werkzeugs, kein Messfehler. Im Befund notierst du, wo du gemessen hast und bei welcher Fensterbreite, denn der Text verschiebt sich mit der Breite über dem Bild.
• Beispiel B – nicht erfüllt. Fließtext #A1A7B0 auf #FFFFFF: 2,42:1 bei einer Schwelle von 4,5:1. Hellgrau auf Weiß ist der häufigste Befund überhaupt; betroffen sind Menschen mit eingeschränktem Sehen und alle bei Sonne auf dem Bildschirm.
• Beispiel C – erfüllt. Derselbe Text in #4A5361 auf #FFFFFF: 7,77:1.
• Beispiel D – erfüllt. #949494 auf #FFFFFF ergibt 3,03:1. Die Zeile ist 24 CSS-Pixel groß (18 Punkt) und gilt damit als großer Text: Schwelle 3:1, knapp darüber.
• Beispiel E – nicht erfüllt. Gleiche Größe, aber #969696 auf #FFFFFF: 2,96:1. Mit bloßem Auge ist der Unterschied zu Beispiel D nicht zu sehen – deshalb wird gemessen und nicht gerundet.
• Beispiel F – nicht erfüllt. Dieselbe Farbe wie in Beispiel D (3,03:1), aber die Zeile ist nur 18 CSS-Pixel groß und fett. Das sind 13,5 Punkt – fetter Text gilt erst ab 14 Punkt (rund 18,7 CSS-Pixel) als groß. Also gilt 4,5:1.
• Beispiel G – erfüllt (Ausnahme). Die Schaltfläche ist wirklich inaktiv (disabled, im Barrierefreiheitsbaum als deaktiviert geführt, nicht fokussierbar). Ihr Text (#A0A0A0 auf #EFEFEF, 2,27:1) fällt unter die Ausnahme für inaktive Bedienelemente. Ob so blasse Schaltflächen eine gute Idee sind, ist eine Frage der Gebrauchstauglichkeit. Das Gegenstück – eine Schaltfläche, die nur so aussieht – ist Stelle 6 bei 1.4.11.
• Beispiel H – erfüllt (Ausnahme). Die Wortmarke (#7FBFC9 auf #FFFFFF, 2,06:1) ist ein Logo; für Text in Logos gibt es keine Kontrastanforderung. Der Alternativtext sorgt für 1.1.1.
• Beispiel I – erfüllt (Ausnahme). Die Titel auf den Buchrücken haben nur rund 2,2:1 bis 2,5:1. Sie sind aber Schrift als Teil eines Bildes mit wesentlichem anderem Inhalt – beiläufig, nicht die Information, um die es geht. Dasselbe gilt für ein Straßenschild im Foto und für rein dekorative Schrift. Die Bildunterschrift darunter ist normaler Text und besteht.
• Beispiel J – nicht erfüllt. Weiße Überschrift (24 CSS-Pixel fett, also großer Text mit Schwelle 3:1) auf einem Verlauf von #0B2A5B nach #8EC3F0. Gemessen wird an der hellsten Stelle, über der noch Text steht – am Zeilenende. Der Verlauf erreicht seine hellste Farbe schon bei 60 % der Kastenbreite. Links außen sind es 14,03:1, bei 30 % der Breite (#4C76A6) 4,72:1, bei 42 % (#6795C3) 3,15:1, bei 45 % (#6D9DCB) 2,86:1 und ab 60 % durchgehend 1,87:1. Ab rund 43 % der Kastenbreite ist 3:1 unterschritten. Die längste Zeile reicht bei jeder Fensterbreite und in jeder geprüften Schrift über 60 % hinaus – an ihrem Ende steht Weiß auf #8EC3F0, also 1,87:1. Die Durchschnittsfarbe des Verlaufs würde das beschönigen; „nicht automatisch messbar“ heißt nicht „nicht prüfbar“.

Automatisch erkennbar? Teilweise – zuverlässig nur bei einfarbigem Hintergrund. axe meldet hier mit der Regel color-contrast die Beispiele B, E und F. Den Platzhalter (Stelle 2) und den Hover-Zustand (Stelle 1) prüft axe nicht; den Text auf dem Foto (Stelle 3) und auf dem Verlauf (Beispiel J) führt es nur unter „zu prüfen“. Inaktive Schaltflächen und Bilder lässt es aus.

Grenzfall: Halbtransparenter Text wird mit der sichtbaren Mischfarbe gemessen. Liegt ein Schatten oder eine Kontur um die Schrift, misst du am sichtbaren Ergebnis. Weichen zwei Messwege voneinander ab, nimm den ungünstigeren Wert und begründe ihn – außer die Abweichung kommt erkennbar von der Kantenglättung.

Verwandte Kriterien: 1.4.11 (Kontrast von Bedienelementen und Grafiken, 3:1), 1.4.1 (fragt nicht nach dem Kontrast, sondern ob Farbe das einzige Merkmal ist), 1.4.5 (Bilder eines Textes).

• Beispiel A – erfüllt. Bei 200 % bricht die Navigation in mehrere Zeilen um, der Hinweiskasten wächst mit dem Text, die Beschriftungen stehen über den Feldern und die Fußzeile bricht um. Nichts geht verloren. Im Beispiel ist keine Höhe und keine Zeilenhöhe in Pixeln festgelegt; auch wenn du in Chrome oder Edge nur die Schriftgröße verdoppelst, wächst alles mit.
• Beispiel B – nicht erfüllt. Dieselbe Seite, aber für schmale Ansichtsbereiche (unter 1280 CSS-Pixel – bei 200 % also in jedem Fenster bis rund 2500 Pixel Breite) gelten feste Maße: (1) Die Navigation hat eine feste Höhe von 44 Pixeln mit overflow: hidden; die Links der zweiten Zeile sind nicht mehr zu sehen. Mit Tab erreichst du sie noch, dann rutscht die Leiste und die ersten Links verschwinden. (2) Der Hinweiskasten ist 72 Pixel hoch bei 24 Pixeln Zeilenhöhe; nach zwei Zeilen ist der Text abgeschnitten. (3) Im Formular stehen die Beschriftungen einzeilig in einer 140 Pixel breiten Spalte und laufen unter die Eingabefelder. (4) Die Fußzeile wird mit „…“ gekürzt; die Öffnungszeiten fehlen, je nach Breite auch die Telefonnummer. Das ist das typische Fehlerbild F69: Text und Bedienelemente werden bei 200 % abgeschnitten oder verdeckt. Betroffen sind Menschen mit eingeschränktem Sehen, die ohne Vergrößerungssoftware arbeiten.
• Beispiel C – erfüllt (Grenzfall). Der Kasten hat feste Maße in Pixeln (200 × 124) und overflow: hidden. Beim Seitenzoom wächst er mit, der Text bleibt vollständig. Mit reinem Textzoom wächst nur die Schrift – dann wird der Satz abgeschnitten. Kursposition: Ein funktionierender Zoom des Browsers genügt; der Fund mit Textzoom gehört als Hinweis in den Bericht, nicht als Verstoß, weil manche Menschen nur die Schrift vergrößern.
• Beispiel D – nicht erfüllt. Die Schriftgröße ist nur in Viewport-Einheiten gesetzt (font-size: 1.5vw). Beim Seitenzoom wird der Ansichtsbereich in CSS-Pixeln halb so breit, die Schrift also in CSS-Pixeln halb so groß – auf dem Bildschirm bleibt sie gleich. In einem 1280 Pixel breiten Fenster sind es 19,2 Pixel bei 100 % und 9,6 CSS-Pixel bei 200 %. Der Text lässt sich mit dem Seitenzoom nicht vergrößern (Fehlerbild F94) – und das in jedem Fenster, egal wie breit.
• Beispiel E – nicht erfüllt. Die Seite sperrt das Vergrößern über die Angabe <meta name="viewport" content="… maximum-scale=1, user-scalable=no">. Auf Smartphones und Tablets ist das Aufziehen mit zwei Fingern oft der einzige Weg zu größerem Text; er ist hier versperrt. Am Desktop merkst du nichts davon, weil der Seitenzoom weiter funktioniert – deshalb im Quelltext nachsehen. Manche Browser (zum Beispiel Safari auf dem iPhone) ignorieren die Sperre inzwischen; ein Verstoß bleibt es.

Seitenzoom und Textzoom: Der Seitenzoom vergrößert alles – Schrift, Bilder, Abstände und alle Maße in Pixeln. Für die Seite wirkt er wie ein schmaleres Fenster: 200 % in einem 1280 Pixel breiten Fenster entsprechen einem Ansichtsbereich von 640 CSS-Pixeln. Fehler entstehen deshalb dort, wo Text bei weniger Platz umbricht und der Kasten nicht mitwächst, oder wo das Layout für schmale Fenster nie mit langen Texten geprüft wurde. Der reine Textzoom vergrößert nur die Schrift; Kästen mit Maßen in Pixeln bleiben, wie sie sind. Die Schriftgröße in den Einstellungen von Chrome und Edge wirkt zudem nur auf Text, der relativ zur Browserschrift gesetzt ist.

Stolperstelle: Beispiel B zeigt die Fehler immer dann, wenn der Ansichtsbereich schmaler als 1280 CSS-Pixel ist. In einem schmalen Fenster siehst du sie schon bei 100 %; in einem sehr breiten Fenster (ab 2560 Pixel) bleibt bei 200 % das breite Layout aktiv und alles sieht richtig aus. Deshalb gehört die Fensterbreite in jeden Befund. Waagerechtes Scrollen bei 200 % ist für 1.4.4 kein Verstoß – das regelt 1.4.10 bei 400 %.

Automatisch erkennbar? Nur die gesperrte Zoom-Angabe: axe (Regel meta-viewport) und Lighthouse melden Beispiel E, wenn du sie auf der Einzelseite laufen lässt. Abgeschnittenen und überlappenden Text findet kein automatisches Werkzeug; in den Beispielen A bis D meldet axe nichts.

Grenzfall: Text, der über eine Schaltfläche hinausläuft, aber lesbar und bedienbar bleibt, ist kein Verlust – höchstens ein Hinweis. Wird die Kopfzeile bei 200 % so hoch, dass kaum noch Inhalt zu sehen ist, aber alles erreichbar bleibt, ist das ebenfalls ein Hinweis.

Verwandte Kriterien: 1.4.10 (Umfluss bei 400 % bzw. 320 CSS-Pixel Breite), 1.4.12 (Textabstände), 1.4.5 (Schrift in Bildern lässt sich gar nicht anpassen).

• Beispiel A – nicht erfüllt. Die Öffnungszeiten sind ein Bild (img). Der Alternativtext ist vollständig, 1.1.1 ist also erfüllt – aber eine Liste mit Zeiten lässt sich ohne Weiteres mit HTML und CSS darstellen, wie Beispiel B zeigt. Wer die Schrift vergrößern, die Farben ändern oder mehr Zeilenabstand braucht, kann das hier nicht. Bei 400 % wird die Schrift unscharf, und in einem schmalen Fenster schrumpft sie mit dem Bild, statt umzubrechen.
• Beispiel B – erfüllt. Dieselben Öffnungszeiten in derselben Gestaltung, aber als Tabelle mit echtem Text: markierbar, bei jeder Vergrößerung scharf, von eigenen Farb- und Abstandseinstellungen erreichbar. Die Gestaltung kommt allein aus dem CSS. Nebenbei kennt ein Screenreader hier Zeilen und Spalten; im Bild gibt es nur einen langen Alternativtext.
• Beispiel C – erfüllt (Ausnahme). Das ist ein Logo. Bei Logos und Wortmarken gilt die Darstellung als wesentlich; sie dürfen als Bild eingebunden sein. Einen Alternativtext brauchen sie trotzdem (1.1.1).

Automatisch erkennbar? Nein. Kein automatisches Werkzeug erkennt, ob ein Bild Text zeigt; axe meldet in diesen drei Beispielen nichts. Du findest Textbilder nur mit den Augen, mit dem Markierversuch und im Code.

Grenzfall: Ein Screenshot einer Software-Oberfläche in einer Anleitung fällt unter die Ausnahme – hier kommt es auf genau diese Darstellung an. Eine Preistabelle als Screenshot dagegen nicht. Schrift auf einem Foto mit viel anderem Inhalt (ein Straßenschild) ist nach der Definition gar kein Bild eines Textes.

Stolperstelle: Markierbarkeit ist nur ein Indiz. Manche Seiten legen unsichtbaren Text über eine Grafik. Text in SVG und in Web-Schriften ist echter Text, Text auf einem canvas nicht.

Verwandte Kriterien: 1.1.1 (der Alternativtext für das Bild), 1.4.3 (auch Bilder eines Textes brauchen Kontrast), 1.4.4 und 1.4.12 (Textgröße und Textabstand lassen sich nur bei echtem Text anpassen).

• Beispiel A – erfüllt. Bei 320 CSS-Pixeln stehen die Spalten untereinander, die Navigation bricht um, Felder und Tabellen passen in die Breite. Es gibt nur senkrechtes Scrollen, alle Inhalte und Funktionen bleiben erreichbar. Die Kopfzeile haftet nur in großen Fenstern am oberen Rand, der Cookie-Hinweis steht bei kleinem Fenster im Textfluss – beides regelt eine Media Query mit Mindestbreite (60 rem) und Mindesthöhe (40 rem).
• Beispiel B – nicht erfüllt. Drei Befunde:
  1. Die Seite ist fest 960 Pixel breit. Bei 320 Pixeln muss man für jede Textzeile waagerecht und für die Seite senkrecht scrollen – genau das schließt das Kriterium aus. Wer mit starker Vergrößerung liest, verliert dabei ständig die Zeile.
  2. Die Kopfzeile ist fest am Fenster verankert (position: fixed) und scrollt deshalb nicht mit. Von den sechs Einträgen der Navigation sind je nach Schrift nur die ersten ein bis zwei ganz zu sehen; mindestens die letzten drei lassen sich mit Maus oder Finger nicht erreichen. Das ist Verlust von Funktion.
  3. Bei 400 % in einem üblichen Fenster bleiben rund 175 Pixel Höhe. Die Kopfzeile belegt davon 100, der Cookie-Hinweis braucht bei 320 Pixeln Breite den Rest und mehr: Vom Inhalt ist nichts zu sehen, und der Hinweis selbst ragt oben aus dem Fenster – sein Anfang ist nicht lesbar und lässt sich nicht herbeiscrollen. Solange er offen ist, ist das Verlust von Inhalt. Nach dem Schließen bleiben unter der Kopfzeile etwa 75 Pixel, rund drei Textzeilen: Die Seiteninhalte sind dann erreichbar, das Lesen ist mühsam – für sich genommen ein Hinweis im Bericht.
  Verletzt außerdem: Schon bei 200 % (640 Pixel) liegt mindestens der letzte Navigationseintrag außerhalb der festen Kopfzeile und ist mit der Maus nicht erreichbar (1.4.4). Die abgeschnittenen Einträge bekommen den Tastaturfokus, ohne dass man ihn sieht (2.4.7). Solange der Cookie-Hinweis offen ist, verdeckt er bei 400 % fokussierte Elemente vollständig (2.4.11).
• Beispiel C – vier Teile erfüllt, Teil 3 nicht erfüllt. Die Seite selbst fließt um; nur einzelne Teile scrollen in sich.
  • Teil 1, Datentabelle – erfüllt (Ausnahme). Sieben Spalten brauchen ein zweidimensionales Layout. Die Tabelle rollt in einem eigenen, per Tastatur erreichbaren Bereich; die Seite nicht. Der Text in den Zellen bricht um.
  • Teil 2, Diagramm – erfüllt (Ausnahme). Würde das Diagramm auf 288 Pixel schrumpfen, wären Achsen und Werte nicht mehr lesbar. Es rollt in sich; die Werte stehen zusätzlich als Text darunter.
  • Teil 3, Stadtplan Fassung 1 – nicht erfüllt. Die Kartenfläche darf in beide Richtungen scrollen. Die Schaltflächen Plus und Minus hängen aber an einer Leiste mit fester Breite von 30 rem in der Karte. In breiten Fenstern stehen sie immer im Bild, unterhalb von rund 500 Pixeln Breite rutschen sie rechts hinaus. Mit der Maus erreicht man sie dann nur, indem man die Karte bis ganz nach rechts verschiebt. Kursposition zum Streitfall: Die Karte ist ausgenommen, ihre Bedienelemente nicht. Verletzt außerdem: Per Tab bekommt Plus bei schmalem Fenster den Fokus, ohne dass man Schaltfläche oder Fokusrahmen sieht (2.4.7).
  • Teil 4, Stadtplan Fassung 2 – erfüllt. Dieselbe Karte, aber Plus und Minus sind am Rahmen der Karte befestigt und rücken in schmalen Fenstern an dessen rechten Rand. Sie bleiben bei jeder Breite und Zoomstufe sichtbar. Das Suchfeld bricht in beiden Fassungen um.
  • Teil 5, Werkzeugleiste – erfüllt (Ausnahme, eng auszulegen). Das Understanding nennt Oberflächen, bei denen eine Werkzeugleiste beim Bearbeiten im Blick bleiben muss. Die Leiste bleibt einzeilig und rollt in sich; umgebrochen würde sie bei 400 % das Textfeld aus dem Fenster schieben. Alle Schaltflächen bleiben per Tastatur und durch Scrollen der Leiste erreichbar. Eine gewöhnliche Navigation oder Filterleiste fällt nicht unter diese Ausnahme.

Die Zeile „Zurück zur Übungsseite“ und die Maßangabe unten rechts auf den Beispielseiten gehören zur Übungsseite, nicht zum Beispiel. Die Maßangabe zeigt Breite und Höhe des Ansichtsfensters ohne Bildlaufleisten.

Automatisch erkennbar? Nein. axe meldet auf keiner der drei Beispielseiten etwas zum Umfluss – auch nicht auf Beispiel B. Geprüft wird von Hand, bei 320 CSS-Pixeln.

Zoom und Gerätemodus weichen ab: Der Gerätemodus stellt nur die Breite ein und lässt das Fenster hoch. Kopfzeile und Cookie-Hinweis von Beispiel B wirken dort harmlos. Beim Zoom schrumpft auch die Höhe – erst dann zeigt sich, wie wenig Fläche bleibt. Maßgeblich ist der Zoom. Außerdem verändert die Skalierung des Betriebssystems die CSS-Breite eines Fensters: messen statt rechnen.

Grenzfall: Klappt die Navigation bei 320 Pixeln in ein Menü mit Schaltfläche zusammen, ist das kein Verlust, solange alle Einträge dort erreichbar sind. Eine feste Kopfzeile, die viel Höhe kostet, ist ein Hinweis; ein Verstoß wird daraus, wenn Inhalte dauerhaft nicht mehr sichtbar oder erreichbar sind.

Verwandte Kriterien: 1.4.4 fragt bei 200 %, ob Text verloren geht – waagerechtes Scrollen ist dort noch kein Verstoß. 2.4.11 gilt, wenn eine feste Kopfzeile das fokussierte Element verdeckt. 1.4.12 prüft die Abstände im Text.

Alle Verhältnisse sind aus den Farbwerten im CSS nach der Formel der WCAG gerechnet.

• Beispiel A, Stelle 4 – nicht erfüllt. Eingabefeld und Link haben einen eigenen Fokusrahmen in Hellblau. Er ist da – 2.4.7 fragt nur danach –, hat aber zu allen angrenzenden Flächen nur 1,86:1. Ob der Fokusrahmen genug Kontrast hat, ist 1.4.11. Betroffen sind sehende Menschen, die mit der Tastatur arbeiten und wenig Kontrast wahrnehmen. Eindeutig ist der Fall am Link: Dort ist der Ring das einzige Zeichen für den Fokus. Im Eingabefeld blinkt zusätzlich der Textcursor, der ebenfalls als Fokusanzeige gilt – ein guter Punkt für die Diskussion, das Urteil hängt am Link. Zum Vergleich: Der Fokusrahmen der Übungsseite (#6A1B9A) hat auf Weiß 9,39:1.
• Beispiel A, Stelle 5 – erfüllt. Die Lupe steht allein, ohne sichtbaren Text – sie ist das, woran man die Schaltfläche erkennt, und braucht 3:1. Mit 5,33:1 besteht sie. Einen Rand braucht die Schaltfläche nicht.
• Beispiel A, Stelle 6 – 1.4.3 nicht erfüllt, 1.4.11 nicht verletzt. Die Schaltfläche sieht inaktiv aus, ist es aber nicht: kein disabled, im Barrierefreiheitsbaum nicht als deaktiviert geführt, sie nimmt den Fokus an und reagiert auf Klick. Damit greift die Ausnahme nicht, und der Text braucht 4,5:1 – er hat 2,08:1. Den blassen Rand misst man mit, er ist aber keine Pflicht, weil der Text die Schaltfläche erkennbar macht. Wäre sie wirklich inaktiv, griffe bei beiden Kriterien die Ausnahme (siehe Beispiel H und bei 1.4.3 das Beispiel G).
• Beispiel B – nicht erfüllt. Das Eingabefeld ist nur an einer Linie unten zu erkennen, und die hat mit #D0D0D0 auf #FFFFFF nur 1,54:1. Die Linie ist hier das einzige Merkmal des Feldes; wer sie nicht sieht, findet keine Stelle zum Hineinklicken.
• Beispiel C – erfüllt. Dasselbe Feld mit einer Linie in #5B6577: 5,88:1. Ein Rahmen rundherum ist nicht verlangt.
• Beispiel D – nicht erfüllt. Zwei Messungen: Die Kästchengrenze (#767676 auf #FFFFFF, 4,54:1) besteht. Der Zustand „angehakt“ aber nicht: Der weiße Haken auf der hellblauen Füllung #CFE3F7 hat nur 1,31:1 – und der Haken ist das, woran man den Zustand erkennt. Die Kästchen sind per CSS gestaltet, also gilt 3:1 auch dafür.
• Beispiel E – erfüllt (Ausnahme). Die Kästchen und ihr Fokusrahmen kommen unverändert vom Browser; für dieses Beispiel setzt das CSS den Fokusrahmen der Übungsseite ausdrücklich auf den Auslieferungszustand zurück (outline: revert). Vom Browser bestimmtes, unverändertes Aussehen ist ausgenommen. Sobald eine Seite Farbe, Breite oder Stil ändert, gilt 3:1. Aktuelle Chromium-Browser zeichnen ohnehin einen zweifarbigen Ring, der auf hellen und dunklen Flächen sichtbar bleibt.
• Beispiel F – erfüllt (Grenzfall). Die Segmente haben untereinander nur 1,04:1 bis 1,28:1 und zum Weiß höchstens 2,09:1. Weil Kategorie und Wert als Text in jedem Segment stehen (#16233A, mindestens 7,51:1), braucht man die Farbflächen nicht mehr, um das Diagramm zu verstehen. Ohne diese Beschriftung bräuchte es 3:1 zwischen angrenzenden Segmenten oder Trennlinien – und eine Legende nur über Farbe wäre zusätzlich 1.4.1.
• Beispiel G – erfüllt (Grenzfall). Das Druckersymbol ist blass (#B0B0B0 auf #FFFFFF, 2,17:1), aber der sichtbare Text daneben sagt dasselbe. Das Symbol wird zum Verstehen nicht gebraucht. Stünde es allein, bräuchte es 3:1.
• Beispiel H – erfüllt (Ausnahme). Auswahlfeld und Symbol-Schaltfläche sind wirklich inaktiv (disabled). Ihr blasser Rand (#D0D0D0, 1,54:1; die Abblendung, mit der Chrome und Edge inaktive Auswahlfelder zeichnen, ist hier abgeschaltet, damit Pipette und CSS denselben Wert liefern) und das blasse Symbol (#C8C8C8, 1,67:1) fallen unter die Ausnahme für inaktive Bedienelemente. Dass darüber steht, warum nichts geht, ist gute Praxis.

Automatisch erkennbar? Nein. axe, WAVE und Lighthouse messen nur Textkontraste; axe meldet in Beispiel A deshalb nur den Text von Stelle 6 (Regel color-contrast, also 1.4.3). Rahmen, Symbole, Häkchen und Fokusrahmen prüfst du von Hand.

Grenzfall: „Angrenzend“ heißt: die Farbe direkt daneben. Ein Rahmen um ein weißes Feld auf hellgrauer Seite wird gegen das Feldinnere und gegen die Seite gemessen; es genügt, wenn die Grenze auf einer Seite 3:1 erreicht. Nicht verlangt sind 3:1 zwischen zwei Zuständen desselben Elements – etwa zwischen dem normalen Aussehen und dem bei Hover.

Verwandte Kriterien: 1.4.3 (Text), 2.4.7 (ob es einen Fokusrahmen gibt), 1.4.1 (Zustand oder Zuordnung nur über Farbe), 4.1.2 (der Zustand „inaktiv“ muss auch im Code stehen).

• Beispiel A – nicht erfüllt. Kästen mit fester Höhe oder Breite halten den größeren Text nicht aus. Fünf Stellen:
  • Navigation: „Termine für Kinder“ und „Ausweis verlängern“ brechen in eine zweite Zeile um. Die Reiter sind aber fest 2,5 rem hoch und schneiden ab (overflow: hidden). Zu lesen ist nur noch „Termine für“ und „Ausweis“.
  • Karten: feste Höhe, der Überlauf ist versteckt. Von „Leihfrist: 14 Tage“ bleibt nur „Leihfrist: 14“ – „Tage“ ist abgeschnitten. Von „Anmeldung bis 2. November“ bleibt „Anmeldung bis“ – das Datum fehlt.
  • Tabelle: feste Spaltenbreiten, kein Umbruch, Überlauf versteckt. Von „Zeitschriften“, „Filme, Spiele“, „28 Tage“ und „14 Tage“ fehlt jeweils das Ende.
  • Beschriftung: Sie wächst von drei auf vier Zeilen, ihr Kasten ist aber auf drei Zeilen festgelegt. Die vierte Zeile liegt im Eingabefeld und überlagert sich mit dem, was man dort eintippt.
  • Schaltfläche: feste Breite, kein Umbruch, Überlauf versteckt – von „Ausweis verlängern“ fehlt das Ende.
  Der Vorher-Nachher-Vergleich gilt für Arial, Helvetica oder Liberation Sans; fehlen alle drei, kann A schon vorher eng sein. Das trifft Menschen, die mit eigenen Abständen lesen, etwa bei Legasthenie oder eingeschränktem Sehen: Ihnen fehlen Termin, Frist und Teile der Navigation.
• Beispiel B – erfüllt. Dieselben Bausteine mit Mindesthöhe und Mindestbreite statt fester Maße. Reiter, Karten und Schaltfläche wachsen mit, die Tabellenzellen brechen um, die Beschriftung schiebt das Feld nach unten. Es sieht anders aus, aber alles bleibt lesbar und bedienbar.
• Beispiel C – erfüllt (Grenzfall). Der Link im Aussehen einer Schaltfläche und die Karte haben eine feste Höhe, der Überlauf bleibt aber sichtbar. Der Text läuft über den Rand hinaus, ist vollständig lesbar, überdeckt nichts, und der Link lässt sich auch am überstehenden Text anklicken. Kein Verlust, also kein Verstoß – im Bericht ein Hinweis. Kippt sofort, wenn der überlaufende Text auf anderem Inhalt landet oder die Schrift außerhalb des Kastens nicht mehr genug Kontrast hat.

Die Schaltfläche „Textabstand nach 1.4.12 einschalten“ und der Lesezeichen-Link gehören zur Übungsseite, nicht zu den Beispielen. Die Schaltfläche legt genau die vier Werte auf die drei Beispiele, das Lesezeichen auf die ganze Seite.

Die Kopiervorlage über den Beispielen setzt dieselben vier Werte wie Lesezeichen und Schaltfläche: * trifft jedes Element, die zweite Regel den Abstand nach Absätzen.

Automatisch erkennbar? Nein. axe meldet in keinem der drei Beispiele etwas dazu. Das Lesezeichen setzt nur die Werte; ob etwas verloren geht, entscheidest du durch Hinsehen.

Grenzfall: Wird Text durch die Abstände mit Auslassungspunkten gekürzt, ist das Kriterium nur erfüllt, wenn der volle Text weiter erreichbar ist, etwa bei Fokus oder auf einer verlinkten Seite. Text in Bildern, in Videos und im canvas fällt nicht unter 1.4.12 – dort lassen sich keine Abstände setzen.

Verwandte Kriterien: 1.4.4 prüft dieselben Fehlerbilder bei 200 % Schriftgröße, 1.4.10 bei 320 CSS-Pixeln Breite. Wer feste Höhen vermeidet, erfüllt meist alle drei.

• Beispiel A, Stelle 1 – erfüllt (Ausnahme). Der Hinweis ist ein natives title-Attribut. Wann er erscheint, wie er aussieht und wann er verschwindet, steuert allein der Browser – solche Anzeigen nimmt das Kriterium aus. Die drei Bedingungen werden hier nicht bewertet. Trotzdem ein Hinweis für den Bericht: Bei Tastaturfokus und auf Touch-Geräten erscheint der Text nicht. Steht wesentliche Information nur im title, ist das ein Thema für 2.1.1, nicht für 1.4.13.
• Beispiel B, Stelle 2 – nicht erfüllt. Schließen mit Esc klappt, der Tooltip bleibt auch stehen und erscheint bei Tastaturfokus. Aber sobald die Maus den Auslöser verlässt, ist er weg – man kommt nicht auf ihn hinauf. Wer mit Bildschirmlupe arbeitet, muss die Maus auf den Tooltip bewegen, um ihn ganz in den vergrößerten Ausschnitt zu holen; auch bei unruhiger Mausführung verschwindet er ständig. Fehlerbild F95.
• Beispiel C, Stelle 3 – erfüllt. Esc schließt den Tooltip, ohne dass Maus oder Fokus sich bewegen. Die Maus kann über die Lücke auf den Tooltip wandern. Er bleibt, solange Maus oder Tastaturfokus auf Auslöser oder Tooltip liegen; von selbst verschwindet er nicht.
• Beispiel D – erfüllt (Sonderregel für Fehlermeldungen). Bei Fokus oder Maus auf dem Feld erscheint eine Meldung zu einem Eingabefehler und verdeckt den Text darunter. Esc schließt sie nicht – das muss es auch nicht: Meldet der Inhalt einen Eingabefehler, entfällt die Bedingung „schließbar“. Hoverbar ist die Meldung, und sie bleibt stehen, bis das Feld verlassen oder die Adresse berichtigt ist; dann gilt sie nicht mehr und verschwindet.
• Beispiel E – erfüllt. Der Hinweis erscheint bei Fokus oder Maus in einer dafür frei gehaltenen Fläche unter dem Feld. Er verdeckt und ersetzt nichts, also muss er nicht schließbar sein. Hoverbar ist er, und er bleibt stehen. Bei 400 % Zoom gegenprüfen: Verdeckt derselbe Inhalt dann doch etwas, gilt die Bedingung wieder.
• Beispiel F – erfüllt, mit Hinweis. Öffne mit „Vormerken …“ den Dialog und geh auf „Jetzt vormerken“. Der Tooltip erfüllt alle drei Bedingungen. Esc schließt ihn – und im selben Zug den ganzen Dialog. Für 1.4.13 zählt nur, dass sich der Tooltip ohne Maus- oder Fokuswechsel schließen lässt. Der Tooltip verdeckt hier „Abbrechen“ ganz: Wer ihn mit Esc loswerden will, um die Schaltfläche zu sehen, verliert den Dialog. Das ist ein Hinweis zur Bedienbarkeit; gehen dabei Eingaben verloren, wird es ein Thema für andere Kriterien (Parkplatz).
• Beispiel G – nicht anwendbar. Der Hinweis erscheint weder bei Hover noch bei Fokus, sondern erst auf Klick, Enter oder Leertaste, und er bleibt bis zum nächsten Klick. Damit fällt er nicht unter 1.4.13. Zu prüfen ist hier anderes: Bedienung mit der Tastatur (2.1.1) und ob die Schaltfläche ihren Zustand meldet (4.1.2, hier über aria-expanded).
• Beispiel H – nicht erfüllt. Das Menü klappt bei Maus oder Tastaturfokus auf „Mein Konto“ auf und schließt mit Esc. Zwischen Schaltfläche und Menü liegt aber eine Lücke ohne verbindende Fläche: Verlässt die Maus die Schaltfläche, klappt das Menü zu, bevor sie ankommt. Nicht hoverbar, Fehlerbild F95 – hier mit der typischen Ursache bei Aufklappmenüs. Mit einer sehr schnellen Bewegung springt der Zeiger manchmal über die Lücke; darauf darf niemand angewiesen sein. Mit der Tastatur sind alle drei Einträge erreichbar.

In B, C und F zählt als Fokus nur der Tastaturfokus: Nach einem Mausklick auf die Schaltfläche hält der Fokus den Tooltip nicht offen, damit die Handgriffe 1 bis 3 in jedem Browser dasselbe ergeben. Der Dialog in F ist nicht modal und steht im Textfluss; die Schaltfläche „Vormerken …“ gehört zum Beispiel.

Touch: Bisher nur in der Touch-Emulation des Browsers geprüft. Dort schließen sich die Tooltips in B und C und das Menü in H gleich nach dem Antippen wieder; die Menüeinträge in H wären dann per Touch nicht erreichbar. Bitte an einem Telefon oder Tablet gegenprüfen. Für 1.4.13 ändert das nichts – es wäre ein Hinweis zur Bedienung per Touch.

Automatisch erkennbar? Nein. axe meldet in keinem der acht Beispiele etwas zu diesem Kriterium. Die drei Bedingungen zeigen sich nur beim Ausprobieren mit Maus und Tastatur.

Grenzfall: Ein Kreuz zum Anklicken genügt als Weg zum Schließen allein nicht – dafür muss man die Maus bewegen. Verlangt ist ein Weg ohne Maus- oder Fokuswechsel, in der Regel Esc.

Verwandte Kriterien: 2.1.1: Tooltips, die nur bei Hover und nie bei Fokus erscheinen, sind ein Tastaturproblem. 4.1.2: In B, C und F ist der Tooltip über aria-describedby mit der Schaltfläche verbunden, in A liefert title die Beschreibung. 3.3.1: In D ist der Fehler zusätzlich dauerhaft am Feld markiert („Eingabe prüfen“).

• Beispiel A – erfüllt. Die drei „Merken“-Schalter sind echte button-Elemente. Sie stehen in der Tab-Reihenfolge und reagieren auf Enter und Leertaste, ohne dass dafür eine Zeile Skript nötig wäre – der Browser macht aus dem Tastendruck einen Klick.
• Beispiel B – nicht erfüllt. Die Schalter sind div-Elemente mit role="button", tabindex="0" und einem Klick-Skript. Der Fokus kommt hin, Rolle, Name und Zustand stimmen (4.1.2 ist erfüllt) – aber Enter und Leertaste bewirken nichts, weil ein div aus einem Tastendruck keinen Klick macht und niemand die Tasten nachgebaut hat. Betroffen sind alle, die ohne Maus arbeiten: mit Tastatur, Schaltersteuerung oder Bildschirmtastatur. Mit laufendem Screenreader fällt es oft nicht auf, weil er selbst einen Klick auslöst – deshalb ohne Screenreader prüfen. Noch häufiger ist die Fassung ganz ohne tabindex und Rolle: Dann wird das Element beim Tabben übersprungen, und zusätzlich ist 4.1.2 verletzt.
• Beispiel C – nicht erfüllt. Das Untermenü erscheint nur, solange der Mauszeiger über „Mein Konto“ steht (CSS :hover). „Mein Konto“ ist ein span ohne Tabstopp, die drei Links darunter sind bis dahin mit display: none versteckt. Per Tastatur – und auch mit dem Screenreader – sind „Ausgeliehene Medien“, „Vormerkungen“ und „Gebühren“ nicht erreichbar.
• Beispiel D – erfüllt. „Mein Konto“ ist eine Schaltfläche mit aria-expanded. Enter oder Leertaste klappt das Untermenü auf, Tab führt durch die Links, Esc klappt zu und setzt den Fokus zurück auf die Schaltfläche. Ob das Untermenü per Enter, Pfeiltasten oder Tab erreichbar ist, lässt das Kriterium offen – es muss nur gehen.
• Beispiel E – nicht erfüllt. Die Reihenfolge lässt sich nur durch Ziehen am Griff ändern. Der Griff ist ein span mit Zeiger-Ereignissen, es gibt keinen Tabstopp und keine Tasten. Start und Ziel zählen, nicht der Weg dazwischen – die Ausnahme für pfadabhängige Eingaben greift also nicht. Verletzt außerdem 2.5.7, weil es auch für Maus und Finger keinen Weg ohne Ziehen gibt. Beide Kriterien getrennt bewerten.
• Beispiel F – erfüllt. Ziehen geht weiterhin, zusätzlich hat jeder Titel die Schaltflächen „nach oben“ und „nach unten“. Sie sind per Tab erreichbar, der Fokus bleibt nach dem Verschieben auf der Schaltfläche, und die neue Position wird als Statusmeldung ausgegeben. Dieselben Schaltflächen erfüllen auch 2.5.7.
• Beispiel G – erfüllt. Der scrollbare Kasten hat tabindex="0", dazu role="region" und einen Namen. Er bekommt den Fokus und lässt sich mit Pfeiltasten, Bild auf, Bild ab und Leertaste scrollen.
• Beispiel H – Grenzfall (browserabhängig); Kursposition: als nicht erfüllt melden. Derselbe Kasten ohne tabindex, und er enthält nichts Fokussierbares. In Chrome, Edge und Firefox erreicht Tab ihn trotzdem: Diese Browser nehmen einen scrollbaren Bereich ohne fokussierbaren Inhalt von selbst in die Tab-Reihenfolge auf – dort siehst du keinen Unterschied zu Beispiel G. Verlassen kann sich eine Seite darauf nicht. Wo ein Browser das nicht tut (probiere Safari am Mac aus), bleiben § 3 bis § 6 für Tastaturnutzende unlesbar, obwohl das Kontrollkästchen darunter das Lesen verlangt. Schreibe in den Befund, in welchem Browser du was beobachtet hast; die Abhilfe kostet ein Attribut.
• Beispiel I – nicht erfüllt. Dieser Kasten rollt nicht von selbst: Er hat overflow: hidden, ein Skript verschiebt den Text beim Drehen am Mausrad, und der Rollbalken am Rand ist nachgebaut und reagiert nur auf Zeiger. Es gibt keinen Tabstopp und keine Tasten – in keinem Browser. Wer ohne Maus arbeitet und den Bildschirm sieht, kommt über den Anfang des Textes nicht hinaus. Mit dem Screenreader fällt es nicht auf, weil der Lesecursor den ganzen Text erreicht.
• Beispiel J – Streitfall, hier nicht erfüllt. Suchfeld und Zoom-Schaltflächen gehen per Tastatur, das Verschieben des Ausschnitts nur durch Ziehen mit der Maus. 2.1.1 verlangt, dass jede Funktion per Tastatur bedienbar ist, nicht jeder einzelne Bedienweg. „Zweigstelle Nord zeigen“ gelingt über die Suche – wäre das die einzige Aufgabe der Karte, wäre das Kriterium erfüllt (Antwort A). „Was liegt im Stadtpark nördlich vom Bahnhof?“ gelingt per Tastatur nicht: Nach der Suche steht der Bahnhof unten rechts im Ausschnitt; Bahnhofstraße, Fluss und Lindenstraße sind zu sehen, der Stadtpark mit der Seebühne nicht – auf keiner Zoomstufe und nach keiner Suche, denn „Stadtpark“ kennt die Suche nicht. Die Umgebung ansehen ist eine Funktion der Karte, also kippt das Urteil zu „nicht erfüllt“ (Antwort B). Antwort C ist falsch: Die Ausnahme für pfadabhängige Eingaben trifft nicht zu, beim Verschieben zählen Start- und Endpunkt. Auch die Kartenausnahme aus 1.4.10 hat mit 2.1.1 nichts zu tun. Abhilfe: Karte fokussierbar machen und auf Pfeiltasten reagieren lassen oder Schaltflächen zum Verschieben ergänzen. Dieselbe Frage stellt sich für Zeigernutzende bei 2.5.7.
• Beispiel K – erfüllt (Ausnahme). Eine Unterschrift von Hand hängt vom gezogenen Weg ab, nicht nur von Start und Ziel. Das Zeichnen selbst muss deshalb nicht per Tastatur gehen. Alles drumherum schon: „Unterschrift löschen“ ist eine echte Schaltfläche. Die Ausnahme macht das Feld nicht benutzbar für Menschen, die keinen Zeiger führen können – eine zweite Möglichkeit, etwa den Namen zu tippen, gehört in die Empfehlung.

Automatisch erkennbar? Kaum. axe meldet hier nur Beispiel H (Regel scrollable-region-focusable: scrollbarer Bereich ohne Tastaturzugang) – also gerade die Stelle, die in vielen Browsern trotzdem funktioniert. Die Beispiele B, C, E, I und J bleiben ohne Meldung, auch der nachgebaute Rollkasten in I: Für das Werkzeug ist er kein scrollbarer Bereich. Ob ein Skript auf Tasten reagiert, findet nur der Durchgang mit der Tastatur heraus.

Grenzfall: Ein Schließen-Symbol, das nur auf die Maus reagiert, während Esc dasselbe erledigt (siehe 2.1.2, Beispiel D): Wer auf die Funktion schaut, sieht 2.1.1 erfüllt; wer auf das Element schaut, nicht. Im Befund begründen, wofür du dich entscheidest.

Verwandte Kriterien: 2.1.2 (Fokus kommt hinein, aber nicht heraus), 4.1.2 (nachgebautes Bedienelement ohne Rolle und Namen), 2.4.7 (Fokus kommt an, ist aber nicht zu sehen), 2.5.7 (Ziehen braucht eine Alternative auch für Zeiger), 1.4.13 (Inhalte, die bei Hover oder Fokus erscheinen).

• Beispiel A – nicht erfüllt. Solange das Beispiel läuft, fängt das Notizfeld Tab und Umschalt + Tab ab, um die Zeile einzurücken. Einen anderen Tastaturweg hinaus gibt es nicht – auch Esc hilft nicht –, und nirgends steht ein Hinweis. Wer per Tastatur, Schalter oder Sprachsteuerung arbeitet, sitzt fest: „Notiz speichern“ und alles danach bleibt unerreichbar, rückwärts genauso. Für diese Menschen ist an dieser Stelle die Nutzung der Seite zu Ende.
• Beispiel B – erfüllt. Dasselbe Feld, dieselbe Einrückung mit Tab. Aber Esc gibt die Tabtaste frei, das nächste Tab oder Umschalt + Tab verlässt das Feld. Weil das kein Weg ist, den man erraten muss, steht er sichtbar am Feld, ist per aria-describedby mit ihm verknüpft und wird nach Esc zusätzlich als Statusmeldung ausgegeben. Genau das verlangt der zweite Halbsatz des Kriteriums.
• Beispiel C – erfüllt. Der modale Dialog hält den Fokus: Tab kreist zwischen E-Mail-Feld, „Abonnieren“ und „Schließen“. Das ist gewollt und keine Falle, denn es gibt Auswege per Tastatur: Esc, die Schaltfläche „Schließen“ und das Absenden. Danach steht der Fokus wieder auf „Newsletter abonnieren“.
• Beispiel D – 2.1.2 erfüllt, aber ein anderes Kriterium nicht (Streitfall aus dem Kurs). Tab kreist im Dialog, das Schließen-Symbol reagiert nur auf die Maus, Esc schließt und setzt den Fokus zurück auf den Auslöser. Esc ist bei Dialogen ein üblicher Ausweg – deshalb ist 2.1.2 erfüllt (Antwort A). Genauer ist Antwort C: Das Symbol ist ein span mit Klick-Skript, ohne Rolle, ohne Namen, ohne Tabstopp. Damit ist 4.1.2 nicht erfüllt. Ob auch 2.1.1 verletzt ist, hängt davon ab, ob man auf die Funktion schaut (Schließen geht mit Esc) oder auf das Element – hier urteilen Prüfende verschieden, also im Befund begründen. Antwort B träfe nur zu, wenn Esc nicht funktionierte und kein anderer Weg aus dem Dialog führte. Empfehlung in jedem Fall: eine sichtbare, fokussierbare Schaltfläche „Schließen“, denn nicht alle kennen Esc.

Zur Steuerung: „Beispiel … starten“ und „Beispiel … stoppen“ gehören zur Übungsseite, nicht zum Beispiel. Beispiel A löst sich nach 20 Sekunden selbst – eine echte Seite täte das nicht. Bewerte es so, als liefe es dauerhaft.

Automatisch erkennbar? Nein. axe meldet in keinem der vier Beispiele etwas. Eine Tastaturfalle findest du nur, indem du hineingehst und wieder herauszukommen versuchst.

Nicht-Beeinträchtigung: 2.1.2 gehört zu den vier Kriterien (mit 1.4.2, 2.2.2 und 2.3.1), die für alle Inhalte einer Seite gelten – auch für solche, für die es eine barrierefreie Alternative gibt. Eine Falle irgendwo auf der Seite verhindert die Konformität der ganzen Seite.

Grenzfall: Ein Cookie-Banner, das modal aussieht, den Fokus aber nicht zu sich holt: Tab läuft hinter dem abgedunkelten Hintergrund weiter. Das ist das Gegenteil einer Falle und kein Fall für 2.1.2, sondern für 2.4.3 – und für 2.4.11, wenn fokussierte Elemente ganz verdeckt sind.

Verwandte Kriterien: 2.1.1 (etwas ist per Tastatur gar nicht bedienbar), 2.4.3 (Fokus beim Öffnen in den Dialog, beim Schließen zurück zum Auslöser), 4.1.2 (Rolle und Name des Dialogs und seiner Bedienelemente).

• Beispiel A – erfüllt. Die Kürzel wirken auf der ganzen Seite, aber es gibt die Einstellung „Tastenkürzel einstellen“: Sie lassen sich ausschalten oder auf Alt + Umschalt + Buchstabe umlegen. Schon eine der beiden Möglichkeiten würde genügen. Dass die Kürzel zunächst eingeschaltet sind, ist erlaubt.
• Beispiel B – nicht erfüllt. j, k, s, l und ? wirken, sobald irgendwo auf der Seite eine dieser Tasten gedrückt wird und kein Textfeld den Fokus hat. Abschalten oder umlegen lässt sich nichts. Wer mit Spracheingabe arbeitet, löst damit unbemerkt Aktionen aus: Die Software tippt ein erkanntes Wort Zeichen für Zeichen. Wird „los“ erkannt, während kein Feld den Fokus hat, löscht das l die aktuelle Nachricht, und das s setzt bei der nächsten einen Stern. Dasselbe passiert Menschen, die öfter versehentlich Tasten treffen.
• Beispiel C – erfüllt. Dieselben Kürzel, aber sie wirken nur, solange der Fokus in der Nachrichtenliste steht – auf einer ihrer Schaltflächen. Steht der Fokus woanders, passiert bei s oder l nichts. Das ist die dritte Möglichkeit des Kriteriums: nur bei Fokus auf dem Bauteil. Die Liste zählt hier als ein Bedienelement; solange der Fokus in ihr steht – etwa nach einem Klick auf „Stern“ –, löst ein diktiertes Wort weiterhin Kürzel aus. Deshalb zusätzlich das Abschalten anbieten.

Zur Steuerung: „Beispiel … starten“ und „Beispiel … stoppen“ gehören zur Übungsseite und zählen nicht als Mechanismus zum Abschalten. Bewerte die Beispiele so, als wären ihre Kürzel ab dem Laden der Seite aktiv.

Automatisch erkennbar? Nein. axe, WAVE und Lighthouse sehen nicht, auf welche Tasten ein Skript reagiert; axe meldet in keinem der drei Beispiele etwas.

Grenzfall: Ein Kürzel aus Umschalt + Buchstabe. Der Normtext nennt Groß- und Kleinbuchstaben ausdrücklich – die Umschalttaste macht aus dem Kürzel keine Kombination im Sinne des Kriteriums. In allen drei Beispielen löst deshalb auch ein großes S den Stern aus. Kürzel über das Attribut accesskey laufen dagegen über Modifikatortasten und fallen nicht unter das Kriterium.

Verwandte Kriterien: 2.1.1 (alles muss auch ohne Kürzel per Tastatur gehen – hier über die Schaltflächen „Stern“ und „Löschen“), 2.5.3 (Spracheingabe braucht den sichtbaren Namen im zugänglichen Namen), 3.2.1 und 3.2.2 (unerwartete Änderungen).

• Beispiel A – nicht erfüllt. Vieles stimmt: Die Warnung kommt 20 Sekunden vor Ablauf, sie steht in einer Region mit role="alert", die Screenreader ohne Fokuswechsel ansagen, und „Reservierung verlängern“ ist eine einfache Aktion. Aber nach der dritten Verlängerung ist Schluss – die Schaltfläche ist dann gesperrt, die nächste Warnung sagt „Eine weitere Verlängerung ist nicht möglich“, und der Termin verfällt. Verlangt sind mindestens zehn Verlängerungen. Wer zum Lesen, Verstehen oder Eingeben deutlich länger braucht oder unterbrochen wird, verliert den Termin trotz Warnung.
• Beispiel B – erfüllt. Dieselbe Warnung zur selben Zeit, dieselbe Schaltfläche – aber sie lässt sich beliebig oft benutzen (im Skript steht keine Obergrenze). Du musst nicht zehn Warnungen abwarten: Die Schaltfläche funktioniert auch vor der Warnung, jede Betätigung zählt mit.
• Beispiel C – nicht erfüllt. Nach 40 Sekunden ist die Reservierung weg, die Auswahl gelöscht. Vorher gibt es keine Warnung und keine Möglichkeit zu verlängern, abzuschalten oder zu verstellen. Die Meldung danach kommt zu spät.

Zur Steuerung: „Beispiel … starten“ und „Beispiel … stoppen“ gehören zur Übungsseite. Das Zeitlimit setzt das Beispiel selbst, sobald ein Termin gewählt ist.

Automatisch erkennbar? Kaum. Werkzeuge finden höchstens eine Weiterleitung oder ein Neuladen per meta-Element (bei axe die Regel meta-refresh). Zeitlimits aus Skripten sehen sie nicht; axe meldet in keinem der drei Beispiele etwas.

Grenzfall: Ein Ticketshop hält Sitzplätze zehn Minuten und gibt sie dann ohne Warnung frei. Echtzeit ist das nicht – eine Auktion wäre es. „Wesentlich“ trägt nur, wenn eine Verlängerung die Sache selbst ungültig machen würde, etwa bei einer Prüfung mit Zeitlimit. Bei knappen Plätzen lässt sich darüber streiten, aber eine Warnung mit Verlängerung ist meist möglich. Kursposition: eher nicht erfüllt, mit Begründung im Befund.

Verwandte Kriterien: 4.1.3 (die Warnung muss auch ohne Fokuswechsel bei Hilfsmitteln ankommen), 2.2.2 (Inhalte, die sich von selbst bewegen oder aktualisieren). Dass Eingaben nach einer erneuten Anmeldung erhalten bleiben und vor Datenverlust gewarnt wird, verlangen erst Kriterien der Stufe AAA – als Empfehlung gehört es trotzdem in den Bericht.

• Beispiel A – erfüllt. Unter dem Laufband steht die Schaltfläche „Laufband anhalten“. Sie ist per Tab erreichbar; angehalten stehen alle vier Meldungen still und vollständig lesbar da, „Laufband fortsetzen“ lässt es weiterlaufen.
• Beispiel B – nicht erfüllt. Das Laufband hält nur an, solange der Mauszeiger darüber steht (CSS :hover). Wer mit Tastatur oder am Touchscreen arbeitet, hat gar keinen Mechanismus, und auch mit der Maus läuft es weiter, sobald man woanders hinzeigt. Betroffen sind Menschen, die sich bei Bewegung am Rand schwer auf den Text konzentrieren können, und alle, die langsamer lesen, als das Band läuft.
• Beispiel C – nicht erfüllt. Der Tipp wechselt alle vier Sekunden. „Voriger Tipp“ und „Nächster Tipp“ blättern, halten den Wechsel aber nicht an – nach vier Sekunden springt das Karussell weiter, auch während man liest oder der Fokus auf einer der Schaltflächen steht. Es fehlt eine Schaltfläche zum Anhalten.
• Beispiel D – nicht erfüllt. Die Zahlen und die Zeile „Zuletzt aktualisiert“ ändern sich alle drei Sekunden, und es gibt nichts, womit sich das anhalten oder verlangsamen ließe. Für automatische Aktualisierung gilt keine Fünf-Sekunden-Grenze. Mit Screenreader wird alle drei Sekunden die Statuszeile angesagt – mitten in alles andere hinein.
• Beispiel E – erfüllt. Dieselbe Tafel mit dem Auswahlfeld „Aktualisierung“: alle 3 Sekunden, alle 30 Sekunden oder angehalten. Den Takt steuern zu können, reicht dem Kriterium bereits; Anhalten geht hier zusätzlich.
• Beispiel F – erfüllt (Ausnahme: wesentlich). Die Ladeanzeige dreht sich acht Sekunden, also länger als fünf, und lässt sich nicht anhalten. Trotzdem ist das Kriterium erfüllt: Sie zeigt einen Ladevorgang an, während dessen es noch nichts zu lesen oder zu bedienen gibt – stell dir vor, die Trefferseite baut sich gerade erst auf –, und ohne sie sähe es aus, als hinge die Seite. Sie endet, sobald die Treffer da sind; Anfang und Ende werden als Statusmeldung ausgegeben.

Zur Steuerung: „Beispiel … starten“ und „Beispiel … stoppen“ gehören zur Übungsseite und zählen nicht als Mechanismus des Beispiels. Das Kriterium betrifft Inhalte, die von selbst starten – bewerte die Beispiele so, als liefen sie ab dem Laden der Seite.

Automatisch erkennbar? Nein. axe kennt nur Regeln für die veralteten Elemente marquee und blink; Bewegung aus CSS oder Skript sehen die Werkzeuge nicht. In den sechs Beispielen meldet axe nichts.

Grenzfall: Die Lade-Animation aus Beispiel F gilt nur deshalb als wesentlich, weil währenddessen ohnehin niemand etwas bedienen kann und ohne Anzeige der Eindruck entstünde, die Seite hänge. Dreht sich dieselbe Anzeige dauerhaft neben Inhalten, die man schon lesen und bedienen kann, braucht sie einen Mechanismus zum Anhalten. Dasselbe gilt für ein Hintergrundvideo, das nur schmückt.

Nicht-Beeinträchtigung: Wie 2.1.2 gilt 2.2.2 für alle Inhalte der Seite – ein Laufband ohne Halt stört das Lesen überall auf der Seite.

Verwandte Kriterien: 2.2.1 (Zeitlimits), 2.3.1 (alles, was schneller als dreimal pro Sekunde blitzt), 1.4.2 (Ton, der von selbst startet). Bewegung nach der Systemeinstellung „Bewegung reduzieren“ abzuschalten (prefers-reduced-motion) ist eine gute Ergänzung, gehört aber zu einem Kriterium der Stufe AAA und ersetzt den Mechanismus auf der Seite nicht.

• Beispiel A – erfüllt. Der Punkt vor „Neu“ blinkt einmal pro Sekunde, also weit unter der Grenze von drei Blitzen pro Sekunde – da braucht es keine Messung. Er hört nach vier Sekunden von selbst auf; damit ist auch 2.2.2 erfüllt, das für Blinken über fünf Sekunden einen Mechanismus zum Anhalten verlangt.
• Beispiel B – nicht erfüllt (nur beschrieben). Zehn Blitze pro Sekunde liegen über der Grenze von drei. Die Ausnahme greift nicht: Die Fläche ist groß, der Wechsel zwischen Weiß und kräftigem Rot ist ein starker Helligkeitssprung und zugleich ein Rotblitz. So ein Banner kann Anfälle auslösen. Im Befund bekommt es die höchste Dringlichkeit: sofort entfernen, nicht erst mit dem nächsten Release.
• Beispiel C – erfüllt (Grenzfall, nur beschrieben). Fünf Blitze pro Sekunde sind mehr als drei – aber die Fläche ist winzig. Unter den Grenzwerten bleibt, was zusammen höchstens ein Viertel eines Sehfelds von 10 Grad einnimmt. Als Faustregel nennt das W3C für dieses Sehfeld ein Rechteck von 341 × 256 Pixeln bei einer Darstellung von 1024 × 768 Pixeln; ein Viertel davon sind rund 21 800 Quadratpixel, das Symbol hat 256. 2.3.1 ist damit erfüllt. Nicht erfüllt ist 2.2.2: Das Symbol blinkt länger als fünf Sekunden und lässt sich nicht anhalten. Empfehlung trotzdem: langsamer als dreimal pro Sekunde, dann stellt sich die Frage nach der Fläche gar nicht.

Warum hier nichts blitzt: Beispiel B wäre gefährlich, und auch Beispiel C soll niemand unvorbereitet sehen. Die Standbilder selbst sind harmlos. Wenn du im Auftrag eine Seite mit Blitzen prüfst: warnen, bevor du den Bildschirm teilst, und eine Aufnahme auswerten statt die Seite laufen zu lassen.

Die Grenzwerte in Kürze: Ein allgemeiner Blitz ist ein Paar gegenläufiger Helligkeitswechsel um mindestens 10 % der größtmöglichen relativen Leuchtdichte, bei dem das dunklere Bild unter 0,80 liegt. Ein Rotblitz ist jedes Paar gegenläufiger Wechsel, an dem ein gesättigtes Rot beteiligt ist. Erfüllt ist das Kriterium, wenn es höchstens drei solcher Blitze pro Sekunde gibt oder die blitzende Fläche klein genug bleibt.

Zur Steuerung: „Beispiel A starten“ und „Beispiel A stoppen“ gehören zur Übungsseite, nicht zum Beispiel.

Automatisch erkennbar? Nein. axe, WAVE und Lighthouse erkennen kein Blitzen; axe meldet in den drei Beispielen nichts. Für Zweifelsfälle gibt es PEAT, im Kurs wird es nur erwähnt.

Nicht-Beeinträchtigung: 2.3.1 gilt für alle Inhalte der Seite, auch für solche, für die es eine barrierefreie Alternative gibt – ein Anfall lässt sich nicht durch eine Alternativfassung ungeschehen machen.

Verwandte Kriterien: 2.2.2 (Blinken und Bewegung, die länger als fünf Sekunden laufen). Blinken ist langsamer und soll Aufmerksamkeit wecken; springt es öfter als dreimal pro Sekunde hin und her, zählt es als Blitzen.

• Beispiel A – nicht erfüllt. Das ist die Beispielsite „Zwei“. Es gibt keinen Sprunglink, keine Landmarks und keine Überschriften-Elemente; der lange Kopf mit vielen Links steht auf jeder Seite vor dem Inhalt. Wer mit der Tastatur arbeitet, tabbt auf jeder Seite erneut durch alle diese Links. Screenreader-Nutzende finden weder eine Landmark noch eine Überschrift, die sie anspringen könnten. Du merkst es am ersten Tab (er landet auf dem ersten Link im Kopf) und an den leeren Listen für Landmarks und Überschriften. Die fehlende Auszeichnung der Überschriften verletzt außerdem 1.3.1.
• Beispiel B – erfüllt. Das ist die Beispielsite „Eins“. Beim ersten Tab erscheint ein Sprunglink, Enter führt in den Hauptinhalt, der nächste Tab landet dort. Dazu kommen header, nav, main und footer sowie Überschriften – mehrere Wege für verschiedene Arbeitsweisen.
• Beispiel C – erfüllt (Grenzfall). Kein Sprunglink, aber saubere Landmarks (header, nav, main, footer) und Überschriften am Beginn jedes Abschnitts. Beides zählt bei der WCAG als ausreichende Technik (ARIA11, H69). Die Schwäche: Sehende Tastaturnutzende ohne Screenreader haben meist keinen Befehl für Landmarks und tabben hier durch alle acht Links der Navigation. Das gehört als Empfehlung in den Bericht, nicht als Verstoß.
• Beispiel D – nicht erfüllt. Der Sprunglink ist da und wird beim Fokus sichtbar, zeigt aber auf #inhalt – und ein Element mit dieser id gibt es nicht (der Inhaltsbereich heißt hauptteil). Nach Enter passiert nichts, der nächste Tab landet in der Navigation. Landmarks und Überschriften-Elemente, die den Mangel auffangen könnten, fehlen ebenfalls (das verletzt außerdem 1.3.1). Ein Mechanismus, der nicht funktioniert, ist keiner.

Die Übungsseite selbst erfüllt das Kriterium: Sprunglink „Zum Inhalt springen“, Landmarks und Überschriften.

Automatisch erkennbar? Teilweise. Die axe-Regel bypass sucht nur nach einem seiteninternen Link, einer Überschrift oder einer Landmark. Auf der Startseite von Beispiel A findet sie nichts davon und führt die Seite unter „zu prüfen“; auf der Seite „Ausleihe“ derselben Website genügt ihr schon der erste Link des Inhaltsverzeichnisses (href="#ausweis"), und sie meldet nichts. In Beispiel D findet sie den Link href="#inhalt" und ist zufrieden – dass das Ziel fehlt, meldet nur die Zusatzregel skip-link aus den „Best Practices“, die in vielen Prüfläufen ausgeschaltet ist. Ob ein Sprunglink ans Ziel führt, zeigt verlässlich nur der Versuch mit der Tastatur.

Grenzfall: Ein Sprunglink darf unsichtbar sein, bis er den Fokus bekommt. Bleibt er auch beim Fokus unsichtbar, ist das ein Befund für 2.4.7. Einzelne wiederholte Wörter oder Links gelten nicht als Block; gemeint sind Bereiche wie Navigation, Kopf oder Werbespalte.

Verwandte Kriterien: 1.3.1 verlangt, dass sichtbare Struktur auch im Code steht – ohne sie gibt es keine Landmarks und Überschriften zum Anspringen. 2.4.3 prüft die Reihenfolge der Tabstopps, 2.4.7 die Sichtbarkeit des Fokus.

• Beispiel A – erfüllt. Das ist die Beispielsite „Eins“. Jeder Titel nennt zuerst das Thema der Seite und dann die Website: „Start – Stadtbücherei Lindenau“, „Ausleihe – Stadtbücherei Lindenau“, „Anmeldung, Schritt 2 von 3: Angaben zur Person – Stadtbücherei Lindenau“. Kein Titel kommt zweimal vor, auch die Schritte der Anmeldung lassen sich am Titel unterscheiden. Wer zwanzig Tabs offen hat, eine Lesezeichenliste durchgeht oder sich den Titel vom Screenreader ansagen lässt, weiß sofort, wo er ist.
• Beispiel B – nicht erfüllt. Das ist die Beispielsite „Zwei“. Start und Ausleihe heißen beide „Home“, alle drei Schritte der Anmeldung „Formular“. Weitere Seiten der Website heißen „Neue Seite 3“ und „Neue Seite 5“, die Bestätigungsseite hat einen leeren Titel. Die Titel sagen nichts über Thema oder Zweck, und mehrere Seiten sind am Titel nicht zu unterscheiden. Betroffen sind Screenreader-Nutzende, die beim Laden und beim Wechsel zwischen Fenstern zuerst den Titel hören, und alle, die mit vielen Tabs, Lesezeichen oder dem Verlauf arbeiten.
• Beispiel C – nicht erfüllt (Grenzfall). Die Anwendung tauscht den ganzen Hauptinhalt aus und ändert die Adresse (#ausleihen, #vormerkungen, #gebuehren), der Titel bleibt aber immer „Mein Konto – Stadtbücherei Lindenau“. Lesezeichen und Verlauf zeigen dreimal denselben Eintrag. Die Erläuterungen des W3C sagen dazu: Wechselt eine Single-Page-Anwendung die Ansicht, soll auch der Titel wechseln. Dagegen lässt sich einwenden, dass für eine Web-Anwendung der Name der Anwendung als Titel genügt – deshalb im Befund begründen, warum die Ansichten hier wie eigene Seiten wirken.
• Beispiel D – erfüllt. Dieselbe Anwendung, aber mit jeder Ansicht wechselt der Titel: „Ausleihen – Mein Konto – Stadtbücherei Lindenau“ und so weiter. Das Skript setzt document.title bei jedem Wechsel neu.

Automatisch erkennbar? Teilweise. axe (Regel document-title), WAVE und Lighthouse melden nur einen fehlenden oder leeren Titel. In der Website von Beispiel B trifft das allein die Bestätigungsseite am Ende der Anmeldung, die nicht unter den fünf verlinkten Seiten ist; auf den fünf Seiten selbst meldet kein Werkzeug etwas zum Titel. Ob „Home“ oder „Neue Seite 3“ die Seite beschreibt, beurteilt kein Werkzeug; in den Beispielen C und D meldet axe nichts.

Grenzfall Prozessschritte: Heißen alle Schritte eines Prozesses gleich („Anmeldung“), ist der Zweck zwar benannt, aber niemand erkennt am Titel, in welchem Schritt er steckt. Beispiel B zeigt das mit dreimal „Formular“; Beispiel A macht es vor: Prozess, Schritt, Thema des Schritts, Website. Ob gleiche, aber treffende Schritttitel schon ein Verstoß sind, ist Ermessen – im Befund begründen.

Stolperstelle: Nicht die Hauptüberschrift prüfen. Eine Seite kann eine treffende h1 haben und trotzdem „Home“ heißen. Das Wichtige gehört nach vorn: Bei „Stadtbücherei Lindenau – Ausleihe“ sieht man in schmalen Tabs nur noch den Namen der Website.

Verwandte Kriterien: 2.4.6 stellt dieselbe Frage an Überschriften und Beschriftungen. 2.4.4: Linktext und Titel der Zielseite passen im besten Fall zusammen. Dass sich ein Ansichtswechsel auch Screenreader-Nutzenden mitteilt, ist eine Frage von Fokusführung (2.4.3) und Statusmeldungen (4.1.3).

• Beispiel A – erfüllt. Beim Öffnen springt der Fokus in den Dialog, auf das erste Bedienelement. Tab und Umschalt + Tab bleiben im Dialog, der Ausschnitt dahinter ist so lange nicht bedienbar (inert). „Reservieren“, „Abbrechen“ und Esc schließen den Dialog, der Fokus kehrt zur Schaltfläche „Platz reservieren“ zurück. Dass der Fokus im offenen Dialog bleibt, ist gewollt und keine Tastaturfalle (2.1.2).
• Beispiel B – nicht erfüllt. Derselbe Dialog, aber das Skript blendet ihn nur ein und aus. Beim Öffnen bleibt der Fokus auf „Platz reservieren“; der nächste Tab läuft durch die drei Links hinter dem Dialog, erst danach kommt die Auswahl. Nach dem Schließen ist der Fokus weg: Je nach Browser geht es am Seitenanfang oder irgendwo hinter dem Dialog weiter, jedenfalls nicht beim Auslöser. Sehende Tastaturnutzende suchen den Fokus, Screenreader-Nutzende bekommen vom Dialog zunächst gar nichts mit. Dazu kommt: aria-modal="true" behauptet, der Rest der Seite sei gesperrt – das stimmt hier nicht (siehe 4.1.2). Du merkst es, wenn du nach dem Öffnen und nach dem Schließen document.activeElement abfragst.
• Beispiel C – nicht erfüllt. Das zugeklappte Menü ist nur zusammengeschoben (max-height: 0, overflow: hidden). Seine vier Links bleiben in der Tab-Reihenfolge: Zwischen „Menü“ und „Öffnungszeiten im November“ drückst du viermal Tab, ohne einen Fokus zu sehen. Screenreader lesen die vier Links vor, obwohl die Schaltfläche „reduziert“ meldet. Manche Prüfende ordnen den verschwundenen Fokus 2.4.7 zu – beides ist vertretbar, im Befund begründen.
• Beispiel D – erfüllt. Das zugeklappte Menü trägt hidden. Seine Links sind damit für alle weg, auch für die Tab-Reihenfolge: Von „Menü“ führt ein Tab zum Link im Text. Aufgeklappt stehen die vier Links im Quelltext und in der Tab-Reihenfolge direkt hinter der Schaltfläche – der nächste Tab nach dem Öffnen landet auf „Katalog“. Stünde ein anderes Bedienelement dazwischen, wäre das ein Fall für den Failure F85.
• Beispiel E – erfüllt. Kein tabindex. Die Reihenfolge folgt dem Quelltext und damit der Seite: Sprunglink, drei Links der Navigation, Vorname, Nachname, Ausweisnummer, E-Mail, Laufzeit, Einwilligung, „Ausweis verlängern“ – und ganz am Ende der Link zurück zur Übungsseite.
• Beispiel F – nicht erfüllt. Fünf Elemente tragen tabindex mit den Werten 1 bis 5. Der Browser läuft diese zuerst ab, in der Folge der Zahlen: Vorname, Nachname, E-Mail, Ausweisnummer, dann schon die Schaltfläche „Ausweis verlängern“. Erst danach kommen Sprunglink und Navigation – und zum Schluss die Laufzeit und die Einwilligung, die vor dem Absenden nötig wären. Wer nur mit der Tastatur arbeitet oder mit Vergrößerung dem Fokus folgt, sendet ab, bevor alles ausgefüllt ist.

Automatisch erkennbar? Kaum. Die Reihenfolge selbst beurteilt kein Werkzeug. axe kennt für positive tabindex-Werte die Regel tabindex, sie gehört aber zu den „Best Practices“ und läuft in einer reinen WCAG-Prüfung nicht mit. In den Beispielen A bis D meldet axe nichts.

Grenzfall: Nach dem Schließen eines Dialogs landet der Fokus am Seitenanfang. In einem langen Prozess ist das nicht erfüllt, weil man seine Stelle verliert. Auf einer kurzen Seite, deren Auslöser ganz oben steht, ist es vertretbar erfüllt. Die Rückgabe an den Auslöser gehört in jede Empfehlung. Ein positiver tabindex ist für sich noch kein Verstoß – er ist nur fast immer die Ursache, wenn die Reihenfolge springt.

Verwandte Kriterien: 1.3.2 betrifft die Lesereihenfolge des Inhalts, 2.4.3 die Reihenfolge der Tabstopps. 2.1.2: Eine Falle hält den Fokus fest, hier geht es darum, wohin er läuft. 2.4.7 fragt, ob der Fokus zu sehen ist, 2.4.11, ob etwas ihn verdeckt. Den Dialog mit allen betroffenen Kriterien gibt es noch einmal als Komponente „Modaler Dialog“ weiter unten auf der Seite.

• Link 1 – erfüllt. Der Link steht im selben Satz wie „Werkzeug und Musikinstrumente“. Der Satz ist programmatisch ermittelbarer Kontext (Technik G53).
• Link 2 – erfüllt. Der Link steht im selben Absatz (p) wie der Text zum Lesesaal (H78). Ein Screenreader liest den Absatz auf einen Tastendruck vor.
• Link 3 – erfüllt. Der Link steht im selben Listenpunkt (li) wie die Lesung (H77).
• Link 4 – erfüllt. Der Link steht in einer Tabellenzelle; die Zeilenkopfzelle „Suchen im Katalog“ und die Spaltenkopfzelle „Infos“ sind ihr über th und scope zugeordnet (H79). Ohne diese Auszeichnung wäre der Kontext nur sichtbar.
• Link 5 – nicht erfüllt (Streitfall, Kursposition). Der Absatz enthält nur den Link; was er meint, steht allein in der Überschrift darüber. Die Überschrift gehört nicht zu dem, was die WCAG als programmatisch ermittelten Linkkontext aufzählt; die Technik dazu (H80) ist bei 2.4.4 nur beratend. In der Linkliste steht „mehr“ ohne jeden Anhaltspunkt. Manche Prüfende bewerten das milder – schreibe das in den Befund. Eine gut begründete Wertung „erfüllt“ ist kein Fehler.
• Link 6 – erfüllt. aria-label="mehr über die Onleihe" gibt dem Link einen Namen, der das Ziel nennt (ARIA8). Der Name beginnt mit dem sichtbaren Text, das passt auch für 2.5.3. Besser wäre trotzdem ein sichtbar vollständiger Linktext: Er hilft auch denen, die die Seite überfliegen oder mit Sprachsteuerung arbeiten.
• Link 7 – erfüllt. Der Linktext lautet vollständig „mehr zum Sommerleseclub“; der zweite Teil ist nur visuell ausgeblendet (C7). So steht er auch in der Linkliste.
• Link 8 – nicht erfüllt. Der Satz zum Förderverein steht in einem eigenen Block neben dem Link – anderer Absatz, anderes div, keine Verbindung im Code (Failure F63). Auf dem Bildschirm wirkt beides zusammengehörig, ein Screenreader liest in der Linkliste und beim Springen von Link zu Link nur „mehr“.

Automatisch erkennbar? Kaum. axe meldet zu keinem der acht Links etwas: Jeder hat einen Namen, und den Kontext beurteilt das Werkzeug nicht. Werkzeuge finden leere Links und Bildlinks ohne Alternativtext; ob ein Kontext zählt, entscheidest du selbst.

Grenzfall: Ist der Zweck eines Links für alle Nutzenden offen – etwa ein Rätsellink „Lass dich überraschen“ –, greift die Ausnahme: Niemand ist im Nachteil. Linktext ganz ohne Kontext verlangt erst 2.4.9 (Stufe AAA).

Verwandte Kriterien: 1.1.1 und 4.1.2, wenn ein Bild der einzige Inhalt eines Links ist und keinen Alternativtext hat. 2.5.3 verlangt, dass der sichtbare Text im zugänglichen Namen vorkommt (Link 6). 2.4.6 stellt dieselbe Frage an Überschriften und Beschriftungen.

• Beispiel A – nicht erfüllt. Das ist die Beispielsite „Zwei“. Zur Seite „Ausleihe“ führen nur Links im Kopf der Seiten: der Punkt in der Hauptnavigation und die Zeilen mit den Schnellzugriffen darüber und darunter. Auch die Auswahlliste „Direkt zu …“ im Kopf gehört dazu: Sie ist dieselbe Linkliste in anderer Form, keine Suche und keine Inhaltsübersicht. Sie fehlt auf den Seiten der Anmeldung, hat keinen Namen und wechselt die Seite schon bei der Auswahl (siehe 4.1.2 und 3.2.2). Das alles ist ein Weg – die Navigation. Eine Suche oder eine Inhaltsübersicht gibt es nicht, und im Inhalt verweist keine Seite auf „Ausleihe“. Menschen, die sich in einer Menüstruktur schwer zurechtfinden, und Menschen, für die jeder Tabstopp Aufwand ist, haben keinen anderen Weg – etwa ein Suchwort einzugeben oder eine Liste aller Seiten zu überfliegen. Du merkst es beim Zählen: Es bleibt bei einem Weg.
• Beispiel B – erfüllt. Das ist die Beispielsite „Eins“. Drei Wege führen zu „Ausleihe“: die Navigation, die Suche (das Suchwort „Ausleihe“ oder „Leihfrist“ findet die Seite) und die Inhaltsübersicht. Zwei hätten genügt, zum Beispiel Navigation und Suche oder Navigation und Inhaltsübersicht.
• Beispiel C – erfüllt (Ausnahme). Schritt 2 der Anmeldung ist ein Schritt in einem Prozess. Er ist nur über Schritt 1 erreichbar und muss es auch nur so sein – für solche Seiten verlangt das Kriterium keinen zweiten Weg. Das gilt, obwohl die Website als Ganzes (Beispiel A) das Kriterium nicht erfüllt: Geprüft wird die einzelne Seite im Seitenverbund. Auch die Bestätigungsseite am Ende ist als Ergebnis eines Prozesses ausgenommen. Erfüllt ist hier nur 2.4.5: Die Seite gehört zur Beispielsite „Zwei“ und hat andere Barrieren.

Automatisch erkennbar? Nein. axe, WAVE und Lighthouse prüfen eine einzelne Seite und zählen keine Wege durch eine Website.

Grenzfall: Querverweise im Inhalt können als Weg zählen (Technik G125): Zur Seite „Veranstaltungen“ führen in Beispiel A neben der Navigation auch Links im Inhalt der Startseite. Ob das genügt, ist Ermessen – für „Ausleihe“ gibt es nicht einmal das. Eine Suche, die nur den Medienkatalog durchsucht, aber nicht die Infoseiten, zählt für die Infoseiten nicht als zweiter Weg – dann braucht es eine Inhaltsübersicht oder Querverweise. Bei kleinen Websites kann auch eine Startseite, die im Inhalt auf alle Seiten verlinkt, als Weg zählen (Technik G185). Besteht eine Website aus nur einer Seite, ist das Kriterium nicht anwendbar.

Verwandte Kriterien: 3.2.3 verlangt, dass die Navigation auf allen Seiten gleich aufgebaut ist; 2.4.1, dass man sie überspringen kann. Alle drei lassen sich nur an mehreren Seiten derselben Website prüfen.

• Beispiel A – nicht erfüllt. In der Überschriftenliste stehen „Informationen“, dreimal „Mehr erfahren“ und „Formular“. Keine davon sagt, worum es im Abschnitt geht, und die drei Karten sind nicht zu unterscheiden. Die Beschriftungen „Nummer“, „Text“ und „Auswahl“ nennen die Art der Eingabe, nicht ihren Zweck: Welche Nummer? Welcher Text? Das trifft Menschen, die per Überschrift navigieren oder Seiten überfliegen, und alle, die im Formular von Feld zu Feld springen und nur die Beschriftung hören. „Absenden“ ist für sich schwach, aber üblich. Weil unklar bleibt, was einzutragen ist, ist je nach Lesart auch 3.3.2 betroffen.
• Beispiel B – erfüllt. Dieselben Inhalte, aber jede Überschrift nennt das Thema ihres Abschnitts und jede Beschriftung den Zweck des Feldes. Die Überschriftenliste liest sich wie ein Inhaltsverzeichnis. Kurz ist erlaubt: „Abholort“ genügt.
• Beispiel C – erfüllt (Grenzfall). „Willkommen“ als oberste Überschrift beschreibt kein Thema – schwach, aber vertretbar, weil die beiden Überschriften darunter das Thema tragen. Das ist Ermessen: im Befund begründen und eine bessere Überschrift empfehlen, etwa „Stadtbücherei Lindenau: Aktuelles“.

Automatisch erkennbar? Nein. axe meldet in keinem der drei Beispiele etwas: Die Überschriften sind als Überschriften ausgezeichnet, jedes Feld hat eine verbundene Beschriftung. Ob der Wortlaut passt, sieht ein Werkzeug nicht.

Grenzfall: Nicht jede schwache Formulierung ist ein Verstoß. „Name“ über einem Namensfeld genügt. Fehlt eine Überschrift ganz, obwohl der Text sichtbar gegliedert ist, gehört das zu 1.3.1; fehlt die Beschriftung eines Eingabefelds, zu 3.3.2.

Verwandte Kriterien: 1.3.1 (Überschriften sind als solche ausgezeichnet), 3.3.2 (Eingabefelder haben Beschriftungen oder Anweisungen), 2.5.3 (die sichtbare Beschriftung steckt im zugänglichen Namen), 2.4.2 (dieselbe Frage für den Seitentitel), 2.4.4 (für Linktexte).

• Beispiel A – erfüllt. Alle fünf Elemente zeigen beim Fokus einen kräftigen Rahmen (3 Pixel, dunkles Violett auf Weiß, rund 9:1). Er erscheint bei Tastaturbedienung (:focus-visible); dass er nach einem Mausklick auf einen Link fehlt, ist zulässig.
• Beispiel B – nicht erfüllt. Für alle fünf Elemente steht im CSS outline: none bei :focus, und einen Ersatz gibt es nicht. Beim Überfahren mit der Maus ändert sich die Fläche, beim Fokus ändert sich nichts. Wer ohne Maus arbeitet und sieht – mit Tastatur, Schalter oder Sprachsteuerung –, weiß nicht, welches Element Enter oder die Leertaste gerade auslöst. Du merkst es beim Tabben: fünf Tastendrücke, nichts zu sehen.
• Beispiel C – erfüllt (Streitfall); 1.4.11 ist nicht erfüllt. Der Fokusrahmen ist da: 2 Pixel in Hellgrau (#d3d3d3) auf Weiß, gemessen 1,5:1. Nach dem Wortlaut fragt 2.4.7 nur, ob eine Fokusanzeige sichtbar ist; eine Kontrastschwelle steht dort nicht. Den Kontrast verlangt 1.4.11: mindestens 3:1 gegenüber angrenzenden Farben für alles, woran man einen Zustand erkennt. Viele Prüfende werten bei einem praktisch nicht wahrnehmbaren Rahmen beide Kriterien als nicht erfüllt. Die Grenze ist Ermessen – im Befund den Messwert nennen und das Urteil begründen, aber denselben Mangel nicht doppelt bewerten.

Automatisch erkennbar? Nein. axe meldet in keinem der drei Beispiele etwas; kein Werkzeug erkennt verlässlich, ob ein Fokus zu sehen ist.

Grenzfall: Sehen Hover und Fokus gleich aus, ist das in Ordnung. Schwierig wird es, wenn sich „Fokus“ und „ausgewählt“ nicht unterscheiden lassen, etwa bei Reitern. Auf farbigen Flächen kann der Standardrahmen des Browsers fast verschwinden – auch das ist dann ein Fall für 1.4.11.

Verwandte Kriterien: 1.4.11 (Kontrast der Fokusanzeige), 2.4.11 (das fokussierte Element ist nicht verdeckt), 2.4.3 (der Fokus steht auf einem unsichtbaren Element – dort Beispiel C). Fläche und Kontrastwechsel der Fokusanzeige regelt erst 2.4.13 auf Stufe AAA.

• Beispiel A – nicht erfüllt. Rückwärts getabbt liegt der Link „Kontakt“ am Ende des Textes vollständig unter der festen Kopfzeile: Er hat den Fokus, zu sehen ist nichts davon. Genau das verbietet das Kriterium (Failure F110). Vorwärts liegen „Datenschutz“ und „Impressum“ nur zur Hälfte unter dem Cookie-Banner – das allein wäre auf Stufe AA zulässig. Dass sich das Banner schließen lässt, hilft nicht: Die Ausnahme für schließbare Inhalte gilt nur für Inhalte, die Nutzende selbst geöffnet haben, und das Banner öffnet die Seite von sich aus. Betroffen sind sehende Tastaturnutzende und Menschen mit Vergrößerung, deren Ausschnitt ohnehin klein ist. Das CSS enthält kein scroll-padding.
• Beispiel B – erfüllt. Dieselbe Seite mit scroll-padding-top und scroll-padding-bottom am html-Element (Technik C43): Der Browser hält beim Fokuswechsel Abstand zu Kopfzeile und Banner. Solange das Banner offen ist, bekommt die Seite außerdem unten so viel Platz, dass die letzten Links darüber stehen. In niedrigen Fenstern (unter 480 CSS-Pixel Höhe, etwa bei 200 % Zoom auf einem Laptop) sind Kopfzeile und Banner nicht mehr fest.
• Beispiel C – erfüllt (Grenzfall). Die Abstände sind zu knapp bemessen: „Kontakt“ liegt rückwärts etwa zur Hälfte unter der Kopfzeile, „Impressum“ zur Hälfte unter dem Banner. Kein Element verschwindet ganz, also ist 2.4.11 erfüllt. Erst 2.4.12 (Stufe AAA) verlangt, dass gar nichts verdeckt ist. In den Bericht gehört es als Empfehlung – wer mit Vergrößerung arbeitet, erkennt an einem halben Wort wenig. Wie in Beispiel B sind Kopfzeile und Banner in niedrigen Fenstern nicht mehr fest, etwa bei 200 % Zoom auf einem Laptop; dann ist gar nichts verdeckt.

Automatisch erkennbar? Nein. axe meldet auf keiner der drei Seiten einen Verstoß. Ob ein Element verdeckt ist, hängt von Fenstergröße, Zoom und Scrollposition ab – das zeigt nur der Durchgang mit der Tastatur, vorwärts und rückwärts.

Grenzfall: Ist das Cookie-Banner ein modaler Dialog, der den Fokus hält, kann nichts Fokussiertes dahinter liegen – dann stellt sich die Frage bei 2.4.3. Inhalte, die Nutzende selbst geöffnet haben (ein Chatfenster, ein aufgeklapptes Menü), dürfen verdecken, wenn sich das fokussierte Element ohne Fokuswechsel wieder freilegen lässt, zum Beispiel mit Esc. Eine Kopfzeile, die beim Scrollen nach unten verschwindet und beim Scrollen nach oben wieder erscheint, taucht gerade beim Rückwärts-Tabben auf: prüfen, nicht vermuten. Wo ein Element nach dem Fokuswechsel genau steht, unterscheidet sich von Browser zu Browser; teste im festgelegten Prüfbrowser.

Verwandte Kriterien: 2.4.7 fragt, ob das Element eine Fokusanzeige hat – hier hat es eine, sie liegt nur unter etwas anderem. 1.4.10: Feste Bereiche, die bei 400 % Zoom den Inhalt zudecken, sind dort ein eigener Befund. Das Kriterium ist neu seit WCAG 2.2; in Prüfungen nach der älteren Fassung gehört es nicht zum Pflichtumfang – im Bericht vermerken.

• Beispiel A – nicht erfüllt. Mit dem Zeiger lässt sich die Karte nur mit zwei Fingern zoomen; es gibt keine Schaltflächen und keinen Doppeltipp. Wer mit einem Finger, einem Mundstab, einer Kopfmaus oder einer gewöhnlichen Maus arbeitet, kommt nicht an die Vergrößerung. Plus und Minus auf der Tastatur helfen bei 2.1.1, zählen hier aber nicht: Gefragt ist ein Weg mit einem einzelnen Zeiger. Verletzt außerdem 2.5.7, weil sich der Ausschnitt mit dem Zeiger nur per Ziehen verschieben lässt.
• Beispiel B – erfüllt. Dieselbe Karte, dazu Schaltflächen für Vergrößern und Verkleinern: einmal tippen genügt. Die Pfeil-Schaltflächen gehören streng genommen zu 2.5.7 – sie ersetzen das Ziehen.
• Beispiel C – erfüllt. Wischen ist eine Pfadgeste; „Zurück“ und „Weiter“ erreichen dasselbe mit einem Tipp.
• Beispiel D – nicht erfüllt. Mit dem Zeiger wechselt der Titel nur durch Wischen. Die Pfeiltasten funktionieren, sobald das Karussell den Fokus hat – das genügt für 2.1.1 (mit Screenreader nur im Fokusmodus), aber nicht für 2.5.1.
• Beispiel E – erfüllt (Streitfall aus dem Kurs). Die Punkte sind der Weg mit einem einzelnen Zeiger: einmal tippen, der Titel wechselt. Ob die Alternative bequem ist, fragt 2.5.1 nicht. Dass die Punkte nur 10 × 10 CSS-Pixel messen und ihre Mittelpunkte 16 Pixel auseinanderliegen, ist ein eigener Befund unter 2.5.8 – dort nicht erfüllt. Jeder Befund bekommt das Kriterium, das er tatsächlich verletzt.

Automatisch erkennbar? Nein. Kein Werkzeug weiß, welche Gesten ein Skript auswertet. axe meldet in Beispiel E nur die Größe der Punkte (Regel target-size), also 2.5.8.

Grenzfall: Eine freihändige Unterschrift ist eine Pfadgeste, aber der Pfad ist wesentlich – Ausnahme. Der Zwei-Finger-Zoom des Browsers und die Wischgesten von VoiceOver oder TalkBack sind nicht gemeint; geprüft werden nur Gesten, die der Inhalt selbst auswertet. Im Code erkennst du das an Zeiger- oder Touch-Ereignissen (pointerdown, pointermove, touchmove) und an touch-action im CSS.

Verwandte Kriterien: 2.5.7 betrifft Ziehen, bei dem nur Start und Ziel zählen (Karte verschieben, Regler) – bei einer Pfadgeste zählt der Weg oder die Richtung. 2.1.1 verlangt die Tastatur, 2.5.1 den einzelnen Zeiger; eines ersetzt das andere nicht. 2.5.8 bewertet die Größe der Alternative. Läuft ein Karussell von selbst weiter, ist das 2.2.2.

• Beispiel A – erfüllt. Eine gewöhnliche Schaltfläche mit click: Sie löst erst beim Loslassen aus. Wer wegzieht und außerhalb loslässt, bricht ab.
• Beispiel B – nicht erfüllt. Die Vormerkung ist schon gelöscht, wenn der Finger die Schaltfläche berührt (pointerdown). Wegziehen hilft nicht, das Loslassen stellt nichts wieder her, ein Rückgängig gibt es im Beispiel nicht, und wesentlich ist das frühe Auslösen auch nicht. Das trifft Menschen, die mit Zittern oder eingeschränkter Feinmotorik danebentippen – und am Telefon alle, die an dieser Stelle nur scrollen wollten.
• Beispiel C – erfüllt. Die Werkzeuge zeigen einen pointerdown-Listener, er färbt die Schaltfläche aber nur ein. Gelöscht wird beim click, also beim Loslassen. Entscheidend ist das Verhalten im Wegzieh-Test, nicht der Listener.
• Beispiel D – erfüllt. Hier bewirkt das Herunterdrücken etwas – aber das Loslassen hebt es wieder auf (Umkehr). So arbeiten auch Vorschauen, die nur beim Halten erscheinen.
• Beispiel E – erfüllt (Ausnahme „wesentlich“). Eine Klaviertaste, die erst beim Loslassen klingt, wäre kein Klavier mehr. Dasselbe gilt für Bildschirmtastaturen: Funktionen, die einen Tastendruck nachbilden, gelten als wesentlich.

Die Schaltflächen „Beispiele A bis C zurücksetzen“ und „Ton für Beispiel E“ gehören zur Übungsseite, nicht zu den Beispielen – sie zählen nicht als Rückgängig-Funktion.

Automatisch erkennbar? Nein. axe meldet in diesen Beispielen nichts (nachgeprüft); auch WAVE und Lighthouse haben für dieses Kriterium keine Prüfung. Ob ein Listener etwas auslöst oder nur einfärbt, zeigt nur der Test von Hand.

Grenzfall: Drag and Drop beginnt beim Herunterdrücken und ist trotzdem erlaubt, wenn die Aktion erst beim Loslassen abgeschlossen wird und sich abbrechen lässt – etwa durch Loslassen außerhalb des Ziels (so machen es die Listen bei 2.5.7) – oder danach rückgängig machen lässt. Löst etwas beim Herunterdrücken aus, lässt sich aber rückgängig machen, wertet der Kurs das nicht als Befund; so beschreibt es auch die Failure F101 des W3C. Der Normtext nennt das Rückgängigmachen allerdings nur zusammen mit dem Abschluss beim Loslassen – empfiehl deshalb in jedem Fall, erst beim Loslassen auszulösen.

Stolperstelle: Auch pointerup oder mouseup kann durchfallen – wenn die Funktion beim Loslassen an beliebiger Stelle auslöst, gibt es keinen Abbruch. Gewöhnliche Schaltflächen und Links machen es von selbst richtig; Probleme entstehen fast nur bei eigenen Skripten.

Verwandte Kriterien: 2.5.7 verlangt für Ziehbewegungen einen Weg ohne Ziehen. 2.1.1: Ein Bedienelement, das nur auf Zeiger-Ereignisse hört, ist mit der Tastatur nicht bedienbar – in Beispiel B, D und E funktionieren Eingabetaste und Leertaste. 3.3.4 verlangt bei rechtlich oder finanziell bindenden Eingaben zusätzlich Prüfen, Korrigieren oder Rückgängigmachen.

• Stellen 1, 3 und 5 – erfüllt. Der Name ist Wort für Wort der sichtbare Text: bei Feld und Kontrollkästchen aus dem verknüpften label, beim Link aus seinem Inhalt. Das sind die drei passenden Stellen der Übung.
• Stelle 2 – erfüllt, mit Empfehlung. aria-label="Datei anhängen" ersetzt den sichtbaren Text „Anhängen“, enthält ihn aber als ganzes Wort. Das Kriterium verlangt nur „enthält“. Im Bericht: erfüllt; Empfehlung, den sichtbaren Text an den Anfang des Namens zu stellen, weil manche Sprachsteuerungen dort suchen. Das ist die Zusatzstufe der Übung und derselbe Fall wie „In den Warenkorb“ im Streitfall.
• Stelle 4 – nicht erfüllt. aria-label="Formular abschicken" überschreibt „Senden“ vollständig; das sichtbare Wort kommt im Namen nicht vor. Wer „Klick auf Senden“ sagt, trifft nichts und muss auf Nummern ausweichen. Screenreader-Nutzende mit Sehrest hören etwas anderes, als sie sehen. Das ist die häufigste Ursache.
• Stelle 6 – nicht anwendbar. Die Schaltfläche zeigt nur ein Symbol und keinen Text; 2.5.3 greift nicht. Einen sinnvollen Namen braucht sie trotzdem (1.1.1, 4.1.2) – „Suchen“ ist ein Wort, das man auch ohne Beschriftung errät.
• Stelle 7 – nicht erfüllt (Grenzfall, Kursposition). „Senden“ steckt in „absenden“ nur als Teil eines anderen Wortes. Sprachsteuerung arbeitet mit Wörtern, nicht mit Wortteilen; der Kurs wertet das deshalb als nicht erfüllt. Die ACT-Regel des W3C zu diesem Kriterium („Visible label is part of accessible name“) und axe vergleichen dagegen Zeichenfolgen und lassen den Fall durchgehen – manche Prüfende werten deshalb „erfüllt“. Nenne im Bericht deine Begründung und prüfe es mit der Sprachsteuerung deines Systems nach.
• Stelle 8 – erfüllt. Der Name „Abmelden vom Rundbrief“ beginnt mit dem sichtbaren Text und ergänzt ihn – so soll ein erweiterter Name aussehen. Vergleiche mit Stelle 2.

Die Spalte „Befehl“ nennt das erwartete Ergebnis. Sprachsteuerungen gehen mit Teiltreffern unterschiedlich um – probiere die Befehle auf deinem System aus.

Automatisch erkennbar? Teilweise. axe hat dafür die Regel label-content-name-mismatch; sie ist als experimentell markiert und läuft in der Standardeinstellung nicht mit – auf dieser Seite meldet axe deshalb nichts. Schaltet man die Regel ein (geprüft mit axe-core 4.13), meldet sie nur Stelle 4. Stelle 7 lässt sie durchgehen, weil sie Zeichenfolgen vergleicht und „senden“ in „absenden“ findet; die Stellen 2 und 8 erkennt sie als erfüllt. Verlass dich auf den Vergleich im Barrierefreiheitsbaum.

Grenzfall: Der Name darf mehr enthalten als der sichtbare Text, etwa um zwanzig gleiche Schaltflächen zu unterscheiden („Anmelden: Lesung am 12. November“). Er muss ihn nicht wiederholen, wo keiner steht. Mathematische Zeichen und Formeln gelten als Text und gehören unverändert in den Namen. Zeichen, die nur als Symbol stehen, gelten dagegen nicht als Beschriftung: Die Schaltflächen „+“, „−“ und die Pfeile bei 2.5.1 und 2.5.7 heißen „Vergrößern“, „Verkleinern“, „… nach oben“ – kein Fall für 2.5.3, auch wenn axe solche Stellen mit eingeschalteter Regel als „zu prüfen“ einstuft.

Verwandte Kriterien: Ob es überhaupt einen Namen gibt, prüft 4.1.2; ob die Beschriftung aussagekräftig ist, 2.4.6; ob Felder überhaupt beschriftet sind, 3.3.2. 2.5.3 prüft nur die Übereinstimmung von Gesehenem und Namen.

• Beispiel A – erfüllt. Schütteln leert das Formular, die Schaltfläche „Formular leeren“ tut dasselbe, und das Kontrollkästchen „Auf Schütteln reagieren“ schaltet die Bewegung ab.
• Beispiel B – nicht erfüllt. Die Reaktion auf das Schütteln lässt sich nicht abschalten (Failure F106) – das genügt für das Urteil: Wer zittert oder im Bus sitzt, leert das Formular aus Versehen. Außerdem fehlt eine Schaltfläche, die das Formular in einem Schritt leert; wessen Telefon fest am Rollstuhl montiert ist, muss jedes Feld einzeln von Hand leeren. Ob das Leeren von Hand als Bedienelement für dieselbe Funktion zählt, ist strittig. Mit der Tastatur geht es auf demselben Weg – 2.1.1 werten wir deshalb nicht als verletzt.
• Beispiel C – nicht erfüllt. „Zurück“ und „Weiter“ sind da – die erste Bedingung stimmt. Aber die Reaktion auf das Neigen lässt sich nicht abschalten (Failure F106). Wer das Gerät nicht ruhig halten kann, blättert ständig ungewollt.
• Beispiel D – erfüllt. Schaltflächen und das Kontrollkästchen „Auf Neigen reagieren“: beide Bedingungen stimmen.

Die Schaltflächen zum Starten und Stoppen gehören zur Übungsseite und zählen nicht als Abschalter des Beispiels. Die Sensoren laufen hier erst nach dem Start, damit beim Lesen der Seite nichts von selbst auslöst.

Automatisch erkennbar? Nein. axe meldet in diesen Beispielen nichts (nachgeprüft); auch WAVE und Lighthouse haben für dieses Kriterium keine Prüfung. Ein Hinweis im Code sind Listener für devicemotion und deviceorientation; unter iOS zusätzlich der Aufruf DeviceMotionEvent.requestPermission().

Grenzfall: „Schütteln zum Widerrufen“ unter iOS ist eine Funktion des Systems, kein Inhalt der Website – nicht prüfen. Zeigt eine Seite im Querformat ein anderes Layout, reagiert sie auf die Ausrichtung, nicht auf Bewegung als Bedienung; das ist 1.3.4. Ausgenommen sind Funktionen, für die die Bewegung wesentlich ist (Schrittzähler, Wasserwaage), und Bewegung, die über eine unterstützte Schnittstelle der Barrierefreiheit läuft. Laut W3C kann es auch genügen, wenn die Anwendung eine Systemeinstellung beachtet, mit der Nutzende die Bewegungserkennung abschalten; stütze ein Urteil darauf nur, wenn du die Einstellung auf dem Prüfgerät gefunden und ausprobiert hast.

Verwandte Kriterien: 1.3.4 (Hoch- und Querformat), 2.5.1 (Gesten auf dem Bildschirm statt Bewegung des Geräts), 2.1.1 (dieselbe Funktion per Tastatur – eine Schaltfläche wie in Beispiel A erfüllt beides).

• Beispiel A – nicht erfüllt. Mit dem Zeiger lässt sich die Dauer nur einstellen, indem man den Griff zieht; ein Klick auf die Leiste bewirkt nichts. Die Pfeiltasten funktionieren – das erfüllt 2.1.1, hilft aber niemandem mit Kopfmaus, Mundstab, Augensteuerung oder einem Touchscreen ohne Tastatur. So ist auch der Streitfall „Regler mit Pfeiltasten“ aus dem Kurs zu werten.
• Beispiel B – erfüllt. Ein Tipp auf die Leiste setzt den Griff an diese Stelle, „Kürzer“ und „Länger“ ändern den Wert schrittweise. Ziehen geht weiterhin.
• Beispiel C – erfüllt. Jeder Eintrag hat Schaltflächen „nach oben“ und „nach unten“. Ein Tipp verschiebt um einen Platz; Ziehen bleibt als zweiter Weg.
• Beispiel D – nicht erfüllt. Die Reihenfolge lässt sich mit dem Zeiger nur durch Ziehen am Griff ändern. Die Tastaturbedienung am Griff (Pfeil hoch, Pfeil runter) ersetzt die Zeiger-Alternative nicht; mit einem Screenreader funktioniert sie zudem nur im Fokusmodus.
• Beispiel E – nicht erfüllt (Grenzfall zu 2.5.1). Plus und Minus ersetzen den Zwei-Finger-Zoom – 2.5.1 ist erfüllt. Den Ausschnitt verschiebt man mit dem Zeiger aber nur durch Ziehen; Pfeil-Schaltflächen fehlen. Erfüllt wäre es auch, wenn eine Suche oder eine Liste zum selben Ausschnitt führte. Vergleiche mit Beispiel B bei 2.5.1.

Automatisch erkennbar? Nein. axe meldet in diesen Beispielen nichts (nachgeprüft); auch WAVE und Lighthouse haben für dieses Kriterium keine Prüfung. Kein Werkzeug weiß, was ein Skript beim Ziehen tut.

Grenzfall: Das Eingabefeld input type="range" des Browsers lässt sich meist durch Tippen auf die Leiste setzen; selbst gebaute Regler oft nicht. Das Scrollen der Seite oder eines Bereichs ist nicht gemeint – das stellt der Browser bereit. „Wesentlich“ heißt, dass das Ziehen selbst die Funktion ist (Freihandzeichnen, Unterschrift), nicht, dass die Funktion unwichtig wäre.

Verwandte Kriterien: 2.5.1: Beim Ziehen zählen nur Start und Ziel, bei einer Pfadgeste (Wischen in eine Richtung) der Weg. 2.1.1 verlangt die Tastatur – sie ist zusätzlich nötig, ersetzt die Zeiger-Alternative aber nicht. 2.5.2: Ziehen beginnt beim Herunterdrücken und ist erlaubt, solange erst das Loslassen abschließt und sich das Ziehen abbrechen lässt – in den Listen durch Loslassen außerhalb des Kastens oder mit Esc. 2.5.8 gilt auch für die Alternativ-Schaltflächen.

Gemessen mit getBoundingClientRect() in Chromium bei 100 % Zoom, in fünf Schriften und bei Fensterbreiten von 320 bis 1600 Pixel. Die Maße der Schaltflächen und Symbole stehen im CSS und sind überall gleich. Von Schrift und Fensterbreite hängen nur zwei Angaben ab – die Größe des Links (Ziel 4) und die Entfernung zum nächsten Ziel bei Ziel 2; dort stehen Spannen. Kein Urteil hängt davon ab.

• Ziel 1 – erfüllt. Gemessen: 156 × 36 CSS-Pixel, klar über 24 (Mindestbreite und Höhe stehen im CSS). Für den Bericht: Die Höhe liegt unter 44; wer gestaltet, plant mit 44 × 44 (2.5.5 Zielgröße (Erweitert), Stufe AAA, und die Empfehlung der Plattformen) – im Bericht eine Empfehlung, kein Mangel. Die Schaltfläche „Merkliste drucken“ daneben erreicht mit 180 × 44 die 44 in der Höhe.
• Ziel 2 – erfüllt über den Abstand. Mit 20 × 20 ist das Ziel zu klein. Der 24-Pixel-Kreis um die Mitte reicht aber nur 2 Pixel über den Rand hinaus, und kein anderes Ziel liegt in der Nähe: Bis zum nächsten sind es von der Mitte aus je nach Fensterbreite und Schrift 50 bis 140 Pixel, weit mehr als 12.
• Ziel 3 – nicht erfüllt. Das Ziel misst 20 × 20, und der Nachbar „entfernen“ beginnt 2 Pixel daneben: Die Mittelpunkte liegen 22 Pixel auseinander – weniger als 24, also schneiden sich die Kreise der beiden zu kleinen Ziele. Eine Ausnahme greift nicht: kein Fließtext, keine größere Alternative, kein Bedienelement des Browsers. Wer zittert oder dicke Finger hat, entfernt einen Titel, den er verlängern wollte. Dasselbe gilt für das Nachbarziel und das Paar in der zweiten Zeile.
• Ziel 4 – erfüllt (Ausnahme „im Fließtext“). Der Link ist je nach Schrift 16 bis 21 Pixel hoch und 85 bis 115 breit (hier gemessen: 16 bis 19 hoch; mit Segoe UI unter Windows rechnerisch rund 21) – in jedem Fall niedriger als 24. Er steht aber in einem Satz; seine Höhe ist durch die Zeilenhöhe des umgebenden Textes begrenzt (24,8 Pixel je Zeile). Abstand musst du nicht prüfen.
• Ziel 5 – erfüllt (Ausnahme „gleichwertig“). Das Symbol misst 16 × 16, und „Sortieren“ beginnt 2 Pixel daneben – der Kreis mit Radius 12 schneidet das Nachbarziel (von der Mitte bis zum Rand von „Sortieren“ 10 Pixel). Für sich genommen wäre das nicht erfüllt. Dieselbe Funktion gibt es aber auf derselben Seite groß genug: die Schaltfläche „Merkliste drucken“ (180 × 44). „Sortieren“ selbst ist 104 × 36 groß und braucht keinen Abstand.
• Ziel 6 – erfüllt über den Abstand. Drei Symbole je 20 × 20, Mittelpunkte 28 Pixel auseinander. Die Kreise (Radius 12) schneiden sich nicht, und von der Mitte bis zum Rand des Nachbarn sind es 18 Pixel, mehr als 12. Lägen die Mittelpunkte nur 22 Pixel auseinander wie bei Ziel 3, wäre es nicht erfüllt.
• Ziel 7 – erfüllt. Das sichtbare Lesezeichen ist nur 12 Pixel groß, die Schaltfläche darum aber 28 × 28: Der Innenabstand zählt zur klickbaren Fläche.
• Ziel 8 – erfüllt (Ausnahme „vom Browser bestimmt“). Das Kästchen misst in Chrome und Edge 13 × 13 (andere Browser können um ein, zwei Pixel abweichen); diese Größe gibt der Browser vor, und die Seite hat sie nicht verändert. Zusätzlich vergrößert die verknüpfte Beschriftung die klickbare Fläche. Sobald die Seite das Kästchen per CSS umgestaltet, gilt die Regel wieder.

Zusatzstufe 320 Pixel: Das Urteil ändert sich bei keinem Ziel. Die Maße der Schaltflächen und Symbole und die Abstände in den Paaren (2 Pixel) und im Dreierblock (8 Pixel) sind in CSS-Pixeln festgelegt und bleiben gleich; nachgemessen bei acht Fensterbreiten von 320 bis 1600 Pixel. Es ändert sich nur die Lage der Ziele. Verlass dich trotzdem nicht darauf – auf echten Seiten schrumpfen Abstände in der schmalen Ansicht oft.

Automatisch erkennbar? Teilweise. axe prüft die Größe und den Abstand mit der Regel target-size. Auf dieser Seite meldet axe in Beispiel A die vier Symbole in den Listenzeilen (Ziel 3 mit Nachbar, beide Zeilen) und das Drucker-Symbol (Ziel 5); zu den Zielen 2, 6, 7 und 8 meldet es nichts. Die Meldung zu Ziel 5 zeigt die Grenze: Die Ausnahme „gleichwertig“ kennt das Werkzeug nicht, sie muss ein Mensch bewerten. Auch den Link im Fließtext (Ziel 4) meldet axe nicht.

Grenzfall: Die Abstandsregel heißt nicht „24 Pixel zwischen den Rändern“ – das wäre zu streng. Es geht um den Kreis um die Mitte des zu kleinen Ziels. Eine Linkliste, die nur wie Fließtext aussieht, fällt nicht unter die Ausnahme „im Fließtext“. Kartenpunkte in genauer Lage können als wesentlich gelten. Bei knapper Erfüllung im Bericht eine Empfehlung Richtung 44 × 44 aussprechen.

Verwandte Kriterien: 2.5.5 Zielgröße (Erweitert) verlangt 44 × 44 und gehört zur Stufe AAA – nicht Prüfstandard dieses Kurses. 2.5.1: Die winzigen Punkte am Karussell (dort Beispiel E) sind ein Befund für 2.5.8, nicht für 2.5.1. 1.4.11 fragt, ob man das Symbol erkennt, 4.1.2, ob es einen Namen hat.

• Beispiel A – nicht erfüllt. Am html-Element steht lang="en", der Inhalt ist aber deutsch. Die Angabe ist vorhanden und gültig, nur eben die verkehrte. Ein Screenreader, der die Stimme nach der Sprachangabe wählt, liest den deutschen Text mit englischer Aussprache – das ist kaum zu verstehen. Auch Übersetzungshilfen, Silbentrennung und Rechtschreibprüfung im Browser gehen von Englisch aus. Du merkst es an der Hörprobe und am Blick auf das html-Element.
• Beispiel B – erfüllt. lang="de" am html-Element, der Inhalt ist deutsch. Die Seite stammt aus der Beispielsite „Eins“; dort tragen alle zehn Seiten diese Angabe. In der Beispielsite „Zwei“ hat außer der Seite „Ausleihe“ (Beispiel A) keine Seite ein lang.
• Beispiel C – nicht erfüllt. Das html-Element hat gar kein lang. Der Screenreader nimmt dann seine Standardstimme. Auf einem deutsch eingestellten Rechner klingt das zufällig passend – deshalb fällt der Mangel in der Hörprobe oft nicht auf. Auf einem Gerät mit anderer Standardsprache wird der Text mit der unpassenden Stimme gelesen. Programmatisch bestimmbar ist die Sprache in keinem Fall.

Automatisch erkennbar? Teilweise. Ein fehlendes lang (Beispiel C) melden axe (Regel html-has-lang), WAVE und Lighthouse als Fehler, ebenso einen ungültigen Wert wie lang="deutsch" (axe: html-lang-valid). Zu Beispiel A meldet axe bei diesem Kriterium nichts: en ist ein gültiger Sprachcode, und ob er zum Text passt, prüfen die Werkzeuge nicht. Genau deshalb gehört der Blick ins html-Element zu jeder Prüfung. Auf den Seiten von Beispiel A und C melden die Werkzeuge daneben vieles andere (Kontraste, Bilder ohne Alternativtext, eine Auswahlliste ohne Namen) – das gehört zu anderen Kriterien. Zu Beispiel B meldet axe gar nichts.

Grenzfall: lang="de" und lang="de-DE" sind beide gültig und erfüllen das Kriterium. Bei einer Seite mit mehreren Sprachen gilt als Hauptsprache die, in der der überwiegende Teil geschrieben ist; die übrigen Passagen sind Sache von 3.1.2.

Verwandte Kriterien: 3.1.2 betrifft einzelne Passagen in anderer Sprache, 3.1.1 nur die Angabe für die ganze Seite. Dieselbe Frage stellt sich bei PDF- und Office-Dokumenten (Dokumentsprache).

• Beispiel A – erfüllt. Jede anderssprachige Passage trägt lang: die beiden Buchtitel (cite lang="en", cite lang="fr"), das englische Motto (blockquote lang="en"), die drei Links des Sprachwählers (en, fr, tr) und die drei Kurzinfos. Ein Screenreader mit passenden Stimmen wechselt an jeder Stelle die Aussprache.
• Beispiel B – nicht erfüllt. Derselbe Inhalt ohne ein einziges lang. Die deutsche Stimme liest den englischen Satz, die französische und die türkische Kurzinfo nach deutschen Ausspracheregeln; „Türkçe“ und „Français“ im Sprachwähler sind so kaum zu erkennen – ausgerechnet für die Menschen, die diese Links suchen. Sichtbar ist kein Unterschied zu Beispiel A; du findest ihn nur im Code oder in der Hörprobe.
• Beispiel C – erfüllt (Ausnahmen). Kein lang, und es wird auch keines verlangt: „Chez Louise“ und „Harriet Whitcombe“ sind Eigennamen, „Open Access“ und „Peer-Review“ Fachbegriffe, „Team“, „Feedback“, „Newsletter“ und „Login“ längst Teil der deutschen Sprache. Kennzeichnen darf man solche Wörter, verlangt ist es nicht.
• Beispiel D – nicht erfüllt (Streitfall aus dem Kurs, Antwort B). „Smart Home Hub“ ist ein Produktname, also ein Eigenname, und fällt unter die Ausnahme. Der Slogan „Stay connected, stay in control“ dagegen ist keine Bezeichnung, sondern ein ganzer englischer Satz. Ohne lang="en" liest ihn die deutsche Stimme mit deutscher Aussprache. Wegen des Slogans ist 3.1.2 hier nicht erfüllt. „Beides auszeichnen“ wäre zu streng, „keines, alles Marketing“ dehnt die Ausnahme zu weit.

Automatisch erkennbar? Nein. axe meldet zu Beispiel B und D nichts. Es prüft nur, ob ein vorhandenes lang einen gültigen Wert hat (Regel valid-lang, auch in Lighthouse) – nicht, ob irgendwo eines fehlt. Ob ein Text die Sprache wechselt, erkennt kein automatisches Werkzeug verlässlich.

Grenzfall: Englische Navigationswörter wie „Login“, „Shop“ oder „News“ gelten als eingedeutscht. Faustregel aus dem Kurs (keine Aussage der Norm): Steht das Wort im Duden und wird es deutsch ausgesprochen, braucht es kein lang. Einzelne Wörter zählen im Zweifel zur umgebenden Sprache. Bei Buchtiteln gehen die Meinungen auseinander – manche Prüfende zählen sie zu den Eigennamen; das Urteil zu Beispiel B hängt daran nicht, Motto, Kurzinfos und Sprachwähler sind eindeutig. Und: Die WCAG kennt nur erfüllt oder nicht erfüllt. Der BITV-Test bewertet den Prüfschritt abgestuft über die ganze Seite; ein einzelner kurzer Slogan fiele dort weniger ins Gewicht.

Verwandte Kriterien: 3.1.1 regelt die Hauptsprache der ganzen Seite. Das Attribut hreflang an einem Link nennt die Sprache der Zielseite – ein sinnvoller Zusatz, aber keine Forderung aus 3.1.2.

• Beispiel A – nicht erfüllt. Sobald das Feld „Ausweisnummer“ den Fokus bekommt, öffnet sich ein Hilfefenster, und der Fokus springt hinein. Niemand hat etwas aktiviert – der Fokus allein löst es aus. Das ist ein Kontextwechsel (neues Fenster, Fokus an anderer Stelle). Wer mit der Tastatur durch das Formular geht, landet statt im Feld in einem Fenster; mit Screenreader oder starker Vergrößerung ist kaum nachzuvollziehen, was gerade passiert ist. Im Tab-Durchgang merkst du es sofort: Du wolltest ins Feld und stehst woanders. Das Feld bleibt benutzbar (mit zweimal Umschalt + Tab zurück oder nach „Schließen“), deshalb kein Befund zu 2.1.1 – aber jedes neue Fokussieren öffnet das Fenster wieder. Die Schaltfläche „Wo steht die Ausweisnummer?“ gibt es auch hier; sie ist nicht das Problem.
• Beispiel B – erfüllt. Sieht aus wie Beispiel A, aber das Feld tut beim Fokus nichts. Das Hilfefenster öffnet sich erst, wenn du die Schaltfläche „Wo steht die Ausweisnummer?“ aktivierst. Dass der Fokus dann ins Fenster wandert, ist erwartet: Es ist die Folge einer Aktivierung, nicht des Fokus. „Schließen“ oder Esc bringt den Fokus zur Schaltfläche zurück.
• Beispiel C – erfüllt (Grenzfall). Beim Fokus erscheint unter dem Feld ein Hinweis. Der Fokus bleibt im Feld, es öffnet sich kein Fenster, der Sinn der Seite ändert sich nicht: Inhaltsänderung, kein Kontextwechsel. Der Hinweis ist über aria-describedby mit dem Feld verbunden und wird beim Fokus mit angesagt. Sein Platz ist freigehalten; deshalb verschiebt sich nichts, wenn er erscheint oder verschwindet.

Automatisch erkennbar? Nein. Werkzeuge wie axe, WAVE oder Lighthouse bedienen die Seite nicht; axe meldet zu Beispiel A nichts. Das Verhalten zeigt sich nur beim Bedienen.

Grenzfall: Ein Datumsfeld, das beim Fokus einen Kalender einblendet, ist in Ordnung, solange der Fokus im Feld bleibt. Springt der Fokus dabei in den Kalender, ist es ein Fokuswechsel und damit ein Kontextwechsel: nicht erfüllt. Ein Mega-Menü, das beim Fokus aufklappt, ist für 3.2.1 unkritisch – dann aber 1.4.13 und 2.4.11 prüfen.

Verwandte Kriterien: Ein automatischer Fokussprung nach einer Eingabe gehört zu 3.2.2. Nimmt ein Skript den Fokus beim Fokussieren gleich wieder weg, sind zusätzlich 2.1.1 und 2.4.7 betroffen. 3.2.1 gilt unabhängig davon, wie der Fokus ankommt – auch ein Mausklick ins Feld von Beispiel A öffnet das Fenster.

• Beispiel A – erfüllt. Die Auswahl in der Liste „Region“ ändert zunächst nichts. Erst die Schaltfläche „Anzeigen“ lädt die Seite neu. Eine Schaltfläche zu aktivieren ist keine „Einstellung ändern“ – dort ist ein Kontextwechsel erwartet. Mit den Pfeiltasten kannst du in Ruhe durch alle Regionen gehen.
• Beispiel B – nicht erfüllt. Schon der Wechsel in der Liste lädt die Seite neu: Adresse und Inhalt wechseln, der Fokus steht danach am Seitenanfang und nicht mehr in der Liste. Angekündigt ist das nirgends. Wer mit den Pfeiltasten durch die Optionen geht, löst je nach Browser bei jedem Schritt ein Neuladen aus und muss jedes Mal neu zur Liste zurück; mit Screenreader beginnt die Seite jedes Mal von vorn. Ein Klassiker: die Auswahlliste, die beim Wechsel sofort navigiert.
• Beispiel C – erfüllt, mit Empfehlung (Streitfall aus dem Kurs, Antwort C). Das Verhalten ist dasselbe wie in Beispiel B, aber davor steht sichtbar: „Die Seite lädt nach Auswahl einer Region neu.“ Der Hinweis steht in der Lesereihenfolge vor der Liste und ist zusätzlich per aria-describedby mit ihr verbunden, wird also beim Fokus angesagt. Das Kriterium erlaubt den Kontextwechsel ausdrücklich, wenn er vorher angekündigt ist – „nie zulässig“ (Antwort B) ist zu streng. Antwort A ist nicht verkehrt, aber unvollständig: Im Tastaturtest löst je nach Browser jeder Pfeiltasten-Schritt in der geschlossenen Liste das Neuladen aus. Das ist eine erhebliche Hürde. Ein Weg bleibt: Alt + Pfeil nach unten öffnet die Liste, Enter wählt aus. Deshalb in der Regel kein Verstoß gegen 2.1.1, aber ein Eintrag im Bericht als Empfehlung: Schaltfläche „Anzeigen“ ergänzen.
• Beispiel D – erfüllt. Das Optionsfeld „Bücherbus“ blendet die Auswahl der Haltestelle ein, die Checkbox das Feld für die E-Mail-Adresse. Der Fokus bleibt, wo er ist, die neuen Felder stehen direkt hinter dem Bedienelement, der Sinn der Seite ändert sich nicht: Inhaltsänderung, kein Kontextwechsel.
• Beispiel E – nicht erfüllt. Nach der vierten Ziffer springt der Fokus von selbst ins nächste Feld. Ein Fokuswechsel durch Eingabe ist ein Kontextwechsel, und angekündigt ist er nicht. Wer blind tippt und nach vier Ziffern wie gewohnt Tab drückt, überspringt ein Feld; wer zurückgeht, um einen Tippfehler zu verbessern, wird beim nächsten Zeichen wieder weitergeschoben. Mit einem Hinweis vor den Feldern („Nach vier Ziffern springt die Eingabe ins nächste Feld“) wäre das Kriterium erfüllt.

Automatisch erkennbar? Nein. Werkzeuge wie axe, WAVE oder Lighthouse bedienen die Seite nicht; axe meldet zu Beispiel B und E nichts. Das Verhalten zeigt sich nur beim Bedienen.

Grenzfall: Ein Hinweis unter der Liste oder nur auf einer Hilfeseite genügt nicht – er muss vor dem Bedienelement wahrnehmbar sein. Ob er zusätzlich programmatisch verknüpft sein muss, ist Auslegungssache; empfohlen ist es. Ein Live-Filter, der eine Trefferliste aktualisiert, ohne den Fokus zu verschieben, ist eine Inhaltsänderung – dann aber 4.1.3 prüfen: Wird die Trefferzahl angesagt?

Verwandte Kriterien: 3.2.1 betrifft Kontextwechsel schon beim bloßen Fokus, 3.2.2 solche nach einer Eingabe oder Auswahl. Gibt es bei einer selbst navigierenden Auswahlliste gar keinen Tastaturweg zu jeder Option, kommt 2.1.1 hinzu.

Zur Übungsseite: Ein echtes Neuladen würde dich von der Übungsseite wegführen. Deshalb baut das Beispiel den Kasten neu auf und setzt den Fokus auf die Überschrift der kleinen Seite. Für das Urteil macht das keinen Unterschied.

• Beispiel A – erfüllt. Das ist die Beispielsite „Eins“. Auf jeder Seite dieselbe Folge: Sprunglink, Hilfezeile, Menü „Service“, Logo, Suche, dann die Hauptnavigation mit Start · Ausleihe · Veranstaltungen · Kontakt · Inhaltsübersicht, darunter der Schnellzugriff und im Fuß Kontakt · Inhaltsübersicht · Zum Seitenanfang. Wer sich einmal gemerkt hat, an welcher Stelle ein Menüpunkt steht, findet ihn auf jeder Seite dort wieder. Erlaubte Abweichungen: Der Punkt der aktuellen Seite ist hervorgehoben, und die Seite „Ausleihe“ hat zusätzlich die Navigation „Auf dieser Seite“.
• Beispiel B – nicht erfüllt. Das ist die Beispielsite „Zwei“. Die Hauptnavigation hat überall dieselben vier Punkte, aber in wechselnder Reihenfolge:
  • Seite 1 (Start): Start · Ausleihe · Veranstaltungen · Kontakt
  • Seite 2 (Ausleihe): Start · Veranstaltungen · Ausleihe · Kontakt
  • Seite 3 (Veranstaltungen): Veranstaltungen · Start · Kontakt · Ausleihe
  Das trifft Menschen, die sich die Position merken, statt jedes Mal alles zu lesen: Menschen mit kognitiven Einschränkungen, Screenreader-Nutzende („dritter Link in der Navigation“) und Menschen, die mit starker Vergrößerung nur einen kleinen Ausschnitt sehen. In Code und Darstellung ist die Reihenfolge dieselbe; du findest den Unterschied also mit bloßem Auge wie in der Linkliste.

Kein Befund zu 3.2.3 in Beispiel B: Der Punkt der aktuellen Seite ist hervorgehoben; die Seite „Ausleihe“ hat zusätzlich „Auf dieser Seite“; der Schnellzugriff mit acht Links unter der Hauptnavigation und die zwei Links der letzten Fußzeile stehen überall an derselben Stelle. Dass es in dieser Website weder Sprunglink noch Suche gibt, gehört zu 2.4.1 und 2.4.5 – hier zählt nur die Reihenfolge dessen, was sich wiederholt. Am unteren Fensterrand dieser Website steht eine Hinweisleiste, die die letzte Fußzeile verdeckt. Sie lässt sich nur mit der Maus schließen (×), und zwar nach jedem Laden einer Seite neu – das ist ein eigener Befund zu 2.4.11 und 2.1.1, nicht zu 3.2.3.

Automatisch erkennbar? Nein. axe, WAVE und Lighthouse prüfen jeweils eine einzelne Seite und vergleichen keine Seiten miteinander.

Grenzfall: „Gleiche relative Reihenfolge“ ist großzügiger als „identisch“. Erlaubt sind ein hervorgehobener aktiver Menüpunkt, ein auf der Unterseite ausgeklapptes Untermenü und zusätzliche oder fehlende Punkte. Auf dem Smartphone steckt die Navigation oft in einem Aufklappmenü, am Rechner in einer Leiste – kein Verstoß; verglichen werden Seiten in derselben Darstellung. Eine Startseite mit ganz anderem Kopf ist nur dann ein Problem, wenn dort dieselben Navigationspunkte in anderer Reihenfolge stehen.

Verwandte Kriterien: 3.2.4 fragt nach gleichen Namen für gleiche Funktionen, 3.2.6 nach dem Ort der Hilfe. Die Suche zählt zur Navigation, also hierher. Alle drei lassen sich nur prüfen, wenn die Stichprobe mehrere Seiten mit gemeinsamer Navigation enthält – ebenso 2.4.5.

• Beispiel A – nicht erfüllt. Das ist die Beispielsite „Zwei“. Dieselbe Funktion heißt je Seite anders – die Tabelle unten zeigt drei Funktionen im Vergleich. Wer mit dem Screenreader nach einem bekannten Namen sucht oder per Sprachsteuerung „Drucken klicken“ sagt, findet die Funktion auf der nächsten Seite nicht wieder; Menschen mit kognitiven Einschränkungen müssen jedes Mal neu erschließen, ob das dasselbe ist. Beim Drucken ist nur ein Symbol zu sehen: Dort fällt der Unterschied erst im Barrierefreiheitsbaum oder mit dem Screenreader auf.
• Beispiel B – erfüllt. Das ist die Beispielsite „Eins“. „Drucken“ (Schaltfläche mit Text, das Symbol hat einen leeren Alternativtext) und „Zum Seitenanfang“ heißen auf jeder Seite gleich, sichtbar wie im Namen. „Anmelden“ heißt sichtbar überall gleich; im zugänglichen Namen folgt nach einem Doppelpunkt die Veranstaltung, etwa die Vorlesestunde für Kinder ab 4 Jahren. Das ist einheitlich, nicht wortgleich – wie „PDF 1 herunterladen“ und „PDF 2 herunterladen“.

Wenn dir in Beispiel A der Link zum Seitenanfang fehlt: Am unteren Fensterrand dieser Website steht eine Hinweisleiste, die die letzte Fußzeile verdeckt. Sie lässt sich nur mit der Maus schließen (×), und zwar nach jedem Laden einer Seite neu – das ist ein eigener Befund zu 2.4.11 und 2.1.1, nicht zu 3.2.4. Schließe die Leiste mit der Maus oder lies den Link im Elementbaum bzw. in der Linkliste des Screenreaders.

Automatisch erkennbar? Nein. Die Werkzeuge prüfen einzelne Seiten; ob ein Name zu dem auf einer anderen Seite passt, vergleichen sie nicht.

Grenzfall: Ein Drucker-Symbol mit dem Alternativtext „Drucken“ auf der einen und „Seite drucken“ auf der anderen Seite ist einheitlich genug: erfüllt. „Warenkorb“ und „Einkaufswagen“ für dieselbe Funktion: nicht erfüllt. Ein Pfeil heißt auf Seite 1 „Weiter“ (nächster Artikel) und auf Seite 2 „Weiter“ (nächster Formularschritt): verschiedene Funktionen, also kein Fall für 3.2.4 – dann aber 2.4.4 prüfen. Zwei verschieden benannte Suchfelder auf derselben Seite: Auslegungssache, denn das Kriterium spricht von einer Gruppe von Seiten; im Zweifel als Empfehlung festhalten.

Verwandte Kriterien: 3.2.3 betrifft die Reihenfolge der Navigation, 3.2.4 die Namen. Ob ein Name überhaupt vorhanden ist, klärt 4.1.2 bzw. 1.1.1; ob der sichtbare Text im Namen steckt, 2.5.3.

• Beispiel A – erfüllt. Das ist die Beispielsite „Eins“. Die Zeile „Fragen? Telefon 0000 123456 oder Kontaktformular“ steht auf jeder Seite in der obersten Zeile des Kopfes, direkt nach dem Sprunglink. Achtung beim Urteil: Das ist „erfüllt“ und nicht „nicht anwendbar“. Nicht anwendbar wäre das Kriterium nur, wenn es gar kein Hilfeangebot gäbe.
• Beispiel B – nicht erfüllt. Das ist die Beispielsite „Zwei“. Dieselbe Zeile „Fragen? Telefon 0000 123456 oder Kontaktformular“ wandert:
  • Seite 1 (Start): oberste Zeile im Kopf
  • Seite 2 (Ausleihe): Kasten mitten im Inhalt, vor „Häufige Fragen“
  • Seite 3 (Veranstaltungen): dritte Spalte im Fuß, unter „Hilfe“
  Wer bei einer Aufgabe festhängt und Hilfe braucht, muss sie auf jeder Seite neu suchen. Das trifft vor allem Menschen mit kognitiven Einschränkungen, aber auch alle, die mit Screenreader oder starker Vergrößerung nicht die ganze Seite überblicken.

Einwand „Der Link Kontakt steht doch überall gleich“: Stimmt – der Link „Kontakt“ in der letzten Fußzeile und das Menü „Service“ im Kopf bleiben in Beispiel B an ihrem Platz. Das rettet das Urteil nicht: Telefonnummer und Link zum Kontaktformular wiederholen sich ebenfalls auf mehreren Seiten, und sie wandern. Am unteren Fensterrand dieser Website steht eine Hinweisleiste, die die letzte Fußzeile verdeckt. Sie lässt sich nur mit der Maus schließen (×), und zwar nach jedem Laden einer Seite neu – das ist ein eigener Befund zu 2.4.11 und 2.1.1, nicht zu 3.2.6.

Automatisch erkennbar? Nein. Kein Werkzeug vergleicht den Ort der Hilfe über mehrere Seiten.

Grenzfall: Kontaktlink im Fuß aller Seiten und zusätzlich groß im Inhalt der Kontaktseite: erfüllt – der wiederholte Mechanismus steht einheitlich, der zusätzliche Eintrag ist Inhalt. Chat-Symbol sonst unten rechts, auf der Bestellseite aber oben links: nicht erfüllt. Chat nur auf zwei von zehn Seiten, dort aber an gleicher Stelle: erfüllt – das Kriterium verlangt nicht, dass die Hilfe auf jeder Seite steht.

Verwandte Kriterien: Die Suche gehört nicht zu den vier Hilfearten, sondern zur Navigation: 3.2.3. 3.2.6 ist neu seit WCAG 2.2 und steht auf Stufe A; in EN 301 549 V3.2.1 ist es noch nicht enthalten.

• Beispiel A – nicht erfüllt. Nach dem Abschicken wechselt nur die Rahmenfarbe der betroffenen Felder von Grau zu Rot. Es gibt keinen Text, der das Feld nennt oder den Fehler beschreibt. Wer mit Screenreader arbeitet, erfährt gar nichts; wer Rot und Grau schlecht unterscheidet, sucht vergeblich. Das verletzt außerdem 1.4.1: Die beiden Rahmenfarben sind fast gleich hell (Kontrast untereinander etwa 1,03:1), die Information steckt also allein in der Farbe. Zwei Befunde, eine Ursache.
• Beispiel B – erfüllt. Unter jedem betroffenen Feld steht ein Text, der das Feld nennt und sagt, was nicht stimmt („In der E-Mail-Adresse fehlt das @-Zeichen …“). Das Feld bekommt aria-invalid="true", die Meldung hängt über aria-describedby am Feld, und der Fokus springt in das erste betroffene Feld – ein Screenreader liest also Beschriftung, Zustand und Meldung in einem Zug. Symbol und Text tragen die Information, nicht die Farbe allein. Die Meldungen sagen auch, wie es richtig geht (3.3.3).
• Beispiel C – nicht erfüllt (Streitfall aus dem Kurs). Roter Rahmen plus Warndreieck mit dem Alternativtext „Fehler“. 1.4.1 ist hier erfüllt, denn das Dreieck ist ein zweites Merkmal neben der Farbe. 3.3.1 verlangt aber eine Beschreibung in Text: „Fehler“ sagt nicht, was falsch ist, und sichtbar zu lesen ist es auch nicht. Sehende wie blinde Nutzende wissen nur, dass etwas nicht stimmt.
• Beispiel D – nicht erfüllt. Hier gibt es Text, und er wird sogar angesagt (role="alert", 4.1.3 ist erfüllt). Aber die Meldung nennt weder das Feld noch den Fehler. Bei drei Feldern ist das lästig, bei dreißig eine Sackgasse – besonders mit Vergrößerung, wenn man nur einen Ausschnitt sieht, und für Menschen, denen das Vergleichen und Suchen schwerfällt. Mitverletzt: 3.3.3.
• Beispiel E – erfüllt (Grenzfall). Dieses Formular überlässt die Prüfung dem Browser (required, type="email", min und max). Der Browser setzt den Fokus ins erste betroffene Feld und zeigt dort eine Textblase; Screenreader sagen sie an. In der Prüfpraxis gilt das meist als erfüllt. Schwächen, die du als Empfehlung notierst: Die Blase verschwindet nach kurzer Zeit, zeigt immer nur einen Fehler und ist bei starker Vergrößerung leicht zu übersehen.

Automatisch erkennbar? Nein. WAVE, axe und Lighthouse schicken von sich aus kein Formular ab. Auch im von Hand erzeugten Fehlerzustand meldet axe in diesem Abschnitt nichts – weder in A noch in C oder D: Ob ein Text den Fehler beschreibt, kann kein Werkzeug beurteilen. Das Kriterium ist Handarbeit.

Grenzfall: Prüft ein Formular gar nichts, ist 3.3.1 nicht anwendbar – es gibt dann keinen „automatisch erkannten“ Fehler. Die Verknüpfung der Meldung mit dem Feld über aria-describedby verlangt 3.3.1 nicht ausdrücklich; sie ist gute Praxis und stützt 1.3.1.

Verwandte Kriterien: 1.4.1 fragt, ob die Kennzeichnung nur über Farbe läuft. 4.1.3 fragt, ob eine Meldung angesagt wird, die den Fokus nicht erhält. 3.3.3 fragt, ob die Meldung einen Weg zur Korrektur nennt. 3.3.2 fragt, ob die Anforderung schon vor dem Abschicken sichtbar war.

• Beispiel A – erfüllt. Jedes Feld hat eine sichtbare Beschriftung, die beim Tippen stehen bleibt. Der Stern ist am Anfang erklärt, die Formate für Ausweisnummer und Geburtsdatum stehen vor der Eingabe am Feld, und die Auswahl hat eine sichtbare Frage („Verlängern um“ als legend).
• Beispiel B – nicht erfüllt. Zwei klare Lücken: Der Stern wird nirgends erklärt (Kursposition seit Tag 3: Die fehlende Erklärung gehört zu 3.3.2). Und das Format von Ausweisnummer und Geburtsdatum erfährt man erst aus der Meldung nach dem Abschicken – die Meldung ist ordentlich (3.3.1 und 3.3.3 sind erfüllt), aber die Anweisung kommt zu spät. Zusätzlich steht über „6 Monate / 12 Monate“ keine sichtbare Frage; der Titel „Ausweis verlängern“ legt den Zusammenhang zwar nahe, für sich allein wäre das deshalb der schwächste Grund. Im Code ist alles benannt (aria-label="Verlängern um", required), ein Screenreader bekommt also sogar mehr als ein sehender Mensch. Betroffen sind alle, am stärksten Menschen, die Anforderungen nicht erraten können oder nach einer abgelehnten Eingabe aufgeben.
• Beispiel C – nicht erfüllt (Streitfall aus dem Kurs, Kursentscheidung). Sichtbar sind nur die Platzhalter. Sobald man tippt, sind sie weg: Wer vor dem Absenden noch einmal prüft, nach einer Unterbrechung zurückkommt oder mit Vergrößerung nur einen Ausschnitt sieht, weiß nicht mehr, welches Feld was verlangt. Das aria-label hilft dem Screenreader (4.1.2), ändert an der sichtbaren Beschriftung aber nichts. Bei einem sehr kurzen Login vergeben manche Prüfende „eher erfüllt“ – vertretbar, aber keine Empfehlung; der BIK BITV-Test (Prüfschritt 9.3.3.2) lässt einen Platzhalter nicht als Beschriftung gelten. Der Platzhalter ist hier absichtlich dunkel genug (5,9:1); der übliche hellgraue Platzhalter wäre zusätzlich ein Befund zu 1.4.3.
• Beispiel D – erfüllt (Grenzfall). Das Suchfeld hat keine eigene sichtbare Beschriftung. Die Schaltfläche „Suchen“ direkt daneben übernimmt diese Aufgabe (Technik G167). Für Hilfsmittel trägt das Feld den Namen „Suchen im Katalog“.

Automatisch erkennbar? Kaum. Die Werkzeuge prüfen, ob ein Feld im Code einen Namen hat – nicht, ob ein Mensch eine Beschriftung sieht. B und C haben Namen im Code und bleiben deshalb unauffällig; axe meldet in diesem Abschnitt nichts. Umgekehrt gilt: Meldet WAVE oder Lighthouse „fehlende Beschriftung“, ist das zuerst ein Befund zu 1.3.1 oder 4.1.2, nicht automatisch zu 3.3.2.

Grenzfall: Verlangt ist nicht möglichst viel Text. Ein Feld „Vorname“ braucht keine Anweisung; ein Datum, eine Nummer oder ein Passwort mit Regeln braucht eine.

Verwandte Kriterien: Ob die Beschriftung im Code mit dem Feld verknüpft ist: 1.3.1 und 4.1.2. Ob sie das Feld treffend beschreibt: 2.4.6. Ob der sichtbare Text im zugänglichen Namen steckt: 2.5.3. Schneller Test der Verknüpfung ohne Werkzeug: Klick auf den Beschriftungstext setzt den Fokus ins Feld.

• Beispiel A – erfüllt. Jede Meldung zeigt den Weg zur Korrektur: das Format mit Beispiel, den erlaubten Bereich, bei „31.02.2027“ den Grund (der Februar 2027 hat 28 Tage). Wo die Seite den gemeinten Wert erraten kann – 2026/10/05 oder die Endung .exampel –, bietet sie ihn als Schaltfläche „Vorschlag übernehmen“ an. Die Meldung steht direkt am Feld und ist über aria-describedby damit verbunden; die Schaltfläche folgt als nächster Tab-Stopp.
• Beispiel B – nicht erfüllt. Dieselbe Prüfung, aber jede Meldung lautet „Eingabe ungültig.“ Das Feld ist gekennzeichnet und der Fehler minimal in Text benannt – 3.3.1 ist damit knapp erfüllt. 3.3.3 ist an drei Stellen eindeutig verletzt. Am E-Mail-Feld steht nirgends ein Hinweis: weder beim fehlenden @ noch bei der Endung .exampel, obwohl die Seite beides erkennt. Beim leeren Pflichtfeld sagt die Meldung nicht, dass eine Angabe fehlt. Und bei 31.02.2027 stimmt das Format; den Grund – diesen Tag gibt es nicht – kennt die Seite und nennt ihn nicht. Bei 2026/10/05 und 12 steht der Hinweis („Format TT.MM.JJJJ“, „2 bis 8“) immerhin dauerhaft am Feld und wird mit der Meldung angesagt; ob das als Vorschlag genügt, bewerten Prüfende unterschiedlich. Das Ganze trifft besonders Menschen mit kognitiven Einschränkungen oder Lernschwierigkeiten und alle, die das Formular mit Screenreader oder starker Vergrößerung nicht „mal eben“ nach Hinweisen absuchen können.
• Beispiel C – erfüllt (Ausnahme Sicherheit). „Ausweisnummer oder Passwort stimmt nicht“ verrät absichtlich nicht, welcher Teil nicht stimmt. Ein genauerer Hinweis würde Unbefugten helfen. Sind Felder leer, sagt die Meldung trotzdem, welche fehlen – das gefährdet nichts.

Automatisch erkennbar? Nein. Kein Werkzeug erzeugt die Fehler oder beurteilt den Inhalt einer Meldung; axe meldet in diesem Abschnitt nichts.

Grenzfall: Die Ausnahme Sicherheit deckt Zugangsdaten, nicht jede Passwort-Meldung. Die Regeln für ein neues Passwort („mindestens 12 Zeichen“) vorab und im Fehlerfall zu nennen, gefährdet nichts. Und: Kennt die Seite keine Korrektur – etwa bei einer unbekannten Ausweisnummer –, kann sie auch keine vorschlagen; dann genügt die Beschreibung nach 3.3.1.

Verwandte Kriterien: 3.3.1 ist die Voraussetzung: ohne erkannten Fehler ist 3.3.3 nicht anwendbar. 3.3.2 verlangt die Formatangabe schon vor der Eingabe; sie steht hier in A und B am Feld. Kursposition: Im Fehlerfall gehört der Weg zur Korrektur trotzdem in die Meldung, weil erst sie sagt, was an dieser einen Eingabe nicht passt. Zwingend aus dem Normtext folgt das nicht – deshalb stützt sich das Urteil zu B auf die Stellen ohne jeden Hinweis.

• Beispiel A – erfüllt (geprüft; Kursposition). Die Anmeldung ist verbindlich und kostet Geld – das Kriterium ist anwendbar. Die Seite prüft die Eingabe: Bei 33, bei Buchstaben und beim leeren Feld erscheint eine Meldung am Feld, die Auswahl bleibt stehen, du kannst korrigieren. Das ist der Weg „geprüft“, und ein Weg von dreien genügt. Es ist der schwächste: Einen verrutschten Termin oder „3“ statt „2“ erkennt keine Prüfung, und danach wird sofort gebucht, ohne Übersicht und ohne Stornierung. Das gehört als Empfehlung in den Bericht, nicht als Verstoß.
• Beispiel B – nicht erfüllt. Sieht aus wie A, aber die Seite prüft nichts: 33, abc oder ein leeres Feld werden mit einem Klick verbindlich gebucht. Keine Eingabeprüfung, keine Übersicht oder Rückfrage, keine Rücknahme – keiner der drei Wege. Das trifft alle, die sich leichter vertippen oder verklicken: Menschen mit motorischen Einschränkungen, mit Screenreader oder Spracheingabe, mit Konzentrations- oder Leseschwierigkeiten.
• Beispiel C – erfüllt (bestätigt). Geprüft wird wie in A. Dazu kommt vor dem Abschluss eine Übersicht mit Termin, Plätzen und Summe. „Angaben ändern“ führt zurück ins Formular, die Eingaben bleiben erhalten; erst „Zahlungspflichtig anmelden“ in der Übersicht bucht (Technik G98). Bei jedem Wechsel springt der Fokus auf die Überschrift der neuen Ansicht. So fängt man auch den verrutschten Termin.
• Beispiel D – erfüllt (umkehrbar). Geprüft wird wie in A, gebucht wird sofort. Die Bestätigung nennt aber eine Frist für die kostenlose Stornierung und bietet sie gleich an (Technik G164).
• Beispiel E – nicht anwendbar. Eine Frage an die Bücherei begründet keine rechtliche Verpflichtung, löst keine Zahlung aus, ändert keine gespeicherten Daten und ist kein Test. Im Protokoll steht dann „nicht anwendbar“ mit einem Satz Begründung – nicht „erfüllt“.
• Beispiel F – erfüllt (umkehrbar). Hier werden eigene gespeicherte Daten gelöscht – anwendbar. „Löschen“ fragt nicht nach, aber die Vormerkung landet unter „Gelöschte Vormerkungen“ und lässt sich dort wiederherstellen (Technik G99). Nach jedem Schritt steht der Fokus auf der Meldung, die sagt, was passiert ist.
• Beispiel G – nicht erfüllt. Dieselbe Liste, aber „Löschen“ entfernt die Vormerkung sofort und endgültig: keine Rückfrage, kein Rückgängig. Eine Eingabe, die sich prüfen ließe, gibt es hier nicht – der Weg „geprüft“ fällt also auch aus. Ein Fehlklick kostet den Platz auf der Warteliste.

Die Schaltflächen „zurücksetzen“ über den Beispielen gehören zur Übungsseite. Sie sind keine Stornierung und kein Wiederherstellen im Sinn des Kriteriums.

Automatisch erkennbar? Nein. Kein Werkzeug weiß, ob ein Formular eine Verpflichtung auslöst, und keines geht den Prozess durch. axe meldet in diesem Abschnitt nichts.

Grenzfall „geprüft“ (Kursposition): Der Normtext nennt drei gleichwertige Wege; ein Formular, das Eingaben auf Fehler prüft und korrigieren lässt, erfüllt 3.3.4 auch ohne eigenen Prüfschritt. Nicht erfüllt ist nur, was verbindlich auslöst ohne Eingabeprüfung, ohne Bestätigung und ohne Rücknahme. Der BIK BITV-Test ist strenger: Prüfschritt 9.3.3.4 erwartet vor dem Abschicken eine Anzeige der Daten mit Korrekturmöglichkeit, eine Bestätigung oder eine Rückabwicklung. Wer nach BITV-Test prüft, wertet Beispiel A deshalb anders. Schreib im Bericht dazu, nach welchem Verfahren du geurteilt hast.

Weitere Grenzfälle: Die Übersicht ist da, aber „Ändern“ führt an den Anfang und alle Angaben sind weg: 3.3.4 bleibt erfüllt, das erneute Eintippen ist ein Befund zu 3.3.7. Weitere anerkannte Wege: ein Kontrollkästchen „Ich habe meine Angaben geprüft“ zusätzlich zur Schaltfläche (G155) oder beim Löschen eine Rückfrage vor der Aktion (G168).

Verwandte Kriterien: 3.3.1 und 3.3.3 fragen, wie gut die Meldung ist, wenn die Seite einen Fehler erkennt – für 3.3.4 zählt nur, dass geprüft wird und korrigiert werden kann. 3.3.7 greift, wenn beim Korrigieren Eingaben verloren gehen.

• Beispiel A – nicht erfüllt. Zwei Befunde. Erstens verlangt Schritt 2 Name, Straße, Postleitzahl und Ort ein zweites Mal, ohne dass sich die Lieferadresse übernehmen oder auswählen lässt. Zweitens sind nach der eingebauten Störungsmeldung alle Felder der Rechnungsadresse leer, obwohl an den Eingaben nichts auszusetzen war; dasselbe passiert nach jeder Fehlermeldung, etwa bei einer vierstelligen Postleitzahl. Jede doppelte Eingabe kostet Menschen mit motorischen Einschränkungen Kraft und Zeit, und sie fordert das Gedächtnis: Wer sich Angaben schwer merkt oder mit Spracheingabe, Bildschirmtastatur oder Screenreader arbeitet, macht beim zweiten Mal leichter Fehler.
• Beispiel B – erfüllt. In Schritt 2 trägt „Lieferadresse übernehmen“ die Angaben aus Schritt 1 ein; sie bleiben änderbar, falls die Rechnung woandershin soll. Eine Statusmeldung sagt, was passiert ist. Nach der eingebauten Störungsmeldung, nach jeder Fehlermeldung und beim Zurückgehen bleiben alle Eingaben stehen (Technik G221).
• Beispiel C – erfüllt (Ausnahme Sicherheit). Das neue Passwort wird zweimal verlangt. Weil es verdeckt eingegeben wird, kann man einen Tippfehler nicht sehen; die Wiederholung schützt davor, sich auszusperren. Das Understanding zu 3.3.7 nennt genau diesen Fall als erlaubt.

Die Schaltflächen „zurücksetzen“ gehören zur Übungsseite, nicht zum Prozess.

Automatisch erkennbar? Nein. Die Werkzeuge gehen keinen Prozess durch; axe meldet in diesem Abschnitt nichts.

Grenzfall: „Mein Browser füllt das doch aus“ zählt nicht – das Understanding schließt die Autovervollständigung des Browsers ausdrücklich aus, die Seite selbst muss die Angaben bereitstellen. Das Kriterium gilt nur innerhalb eines Prozesses und einer Sitzung; ein Prozess kann aber über mehrere Seiten oder einen fremden Zahlungsdienst laufen. Weitere Ausnahmen: Die Wiederholung ist wesentlich (Merkspiel), oder die frühere Angabe gilt nicht mehr (abgelaufener Einmalcode). Lädt jemand dieselben Angaben in anderer Form hoch, etwa als Dokument, ist das keine erneute Eingabe im Sinn des Kriteriums.

Verwandte Kriterien: 3.3.4: Führt „Ändern“ in einer Übersicht an den Anfang und alles ist weg, ist das ein Befund zu 3.3.7, nicht zu 3.3.4. 1.3.5: Die autocomplete-Angaben (hier in A und B gesetzt) helfen dem Browser beim Ausfüllen, ersetzen 3.3.7 aber nicht. Neu seit WCAG 2.2 – im Prüfprotokoll vermerken.

• Beispiel A – erfüllt. Ein Passwort zu wissen ist zwar ein kognitiver Funktionstest, aber hier gibt es die Hilfe dazu: Einfügen funktioniert, und die Felder sind mit autocomplete="username" und autocomplete="current-password" ausgezeichnet, sodass Browser und Passwortmanager sie füllen können (Technik H100). Mehr verlangt die Anmeldung nicht.
• Beispiel B – nicht erfüllt. Sieht genauso aus, aber das Passwortfeld blockt das Einfügen (onpaste="return false;", ebenso das Hineinziehen), und Formular und Felder tragen autocomplete="off". Wer sein Passwort aus einem Passwortmanager kopiert, muss es jetzt abtippen oder auswendig wissen – eine Hürde vor allem für Menschen, denen Merken, Lesen oder fehlerfreies Schreiben schwerfällt (Fehlerbild F109). Manche Browser übergehen autocomplete="off" bei Anmeldefeldern; entscheidend ist deshalb der Einfügetest. Mitbetroffen: 1.3.5, weil der Eingabezweck der beiden Felder nicht mehr im Code steht.
• Beispiel C – nicht erfüllt. Einfügen und Passwortmanager funktionieren wie in A. Dazu kommt aber eine Rechenaufgabe als Pflichtschritt. Rechnen ist ein kognitiver Funktionstest, es gibt keinen anderen Weg und keine Hilfe, und Objekterkennung ist es auch nicht. Ausgeschlossen werden zum Beispiel Menschen mit Rechenschwäche oder mit kognitiven Einschränkungen nach einem Schlaganfall.
• Beispiel D – erfüllt (Alternative). Dieselbe Rechenaufgabe wie in C, aber daneben ein zweiter Weg: der Anmeldelink per E-Mail (Technik G218). Die eigene E-Mail-Adresse einzugeben gilt nicht als kognitiver Funktionstest. Ein Schritt mit Test ist zulässig, wenn es eine Anmeldung ohne Test gibt.
• Beispiel E – 3.3.8 nicht anwendbar (Streitfall aus dem Kurs). Hier meldet sich niemand an; das Kriterium gilt nur für Schritte einer Authentifizierung. Das Bilderrätsel ist ein CAPTCHA und wird unter 1.1.1 geprüft: Die Alternativtexte nennen den Zweck („Rätselbild 1 von 6“), aber es fehlt eine Alternative für einen anderen Sinn, etwa ein Audio-CAPTCHA – 1.1.1 ist nicht erfüllt. Stünde dasselbe Rätsel in einer Anmeldung, wäre 3.3.8 über die Ausnahme Objekterkennung erfüllt, 1.1.1 gälte zusätzlich.

Automatisch erkennbar? Nein. Kein Werkzeug fügt etwas ein oder erkennt ein Rätsel; autocomplete="off" ist ein gültiger Wert und wird nicht beanstandet. axe meldet in diesem Abschnitt nichts.

Grenzfall: Ein Bestätigungscode in sechs Einzelfeldern ist erst dann ein Verstoß, wenn sich der ganze Code nicht einfügen lässt. Die Abfrage einzelner Zeichen („das 3. und 5. Zeichen deines Passworts“) kann kein Passwortmanager ausfüllen – ohne Alternative nicht erfüllt. Das Anlegen eines Kontos ist keine Authentifizierung: Ein CAPTCHA im Registrierungsformular ist ebenfalls ein Fall für 1.1.1.

Verwandte Kriterien: 3.3.9 Barrierefreie Authentifizierung (erweitert) ist Stufe AAA und nicht Teil des Prüfstandards; dort fallen die Ausnahmen Objekterkennung und eigene Inhalte weg. 3.3.7 regelt die Wiederholung von Eingaben, etwa „Passwort wiederholen“. Neu seit WCAG 2.2 – im Prüfprotokoll vermerken.