Ihr Prüfbericht meldet 2.1.1 als Fehler bei jedem Element. So finden Sie heraus, ob das stimmt.

Jemand schickt Ihnen einen Barrierefreiheitsbericht. Unter 2.1.1 Tastatur trägt jedes Element derselbe Befund: keine Alternative zur reinen Mausbedienung. Sie ziehen die Maus ab, tabben durch die Seite, und alles funktioniert — der Fokus wandert, der Rahmen ist sichtbar, Enter löst aus, was es soll.

Einer von beiden irrt. Herauszufinden, wer, ist keine Meinungsfrage, und die Antwort ist interessanter als „der Dienstleister bläht den Bericht auf".

Erstens: 2.1.1 bedeutet nicht, was der Bericht vermutlich unterstellt

Das Kriterium lautet:

Alle Funktionalitäten des Inhalts sind über eine Tastaturschnittstelle bedienbar, ohne dass es einer bestimmten Zeitvorgabe für einzelne Tastenanschläge bedarf, außer wenn die zugrundeliegende Funktion eine Eingabe erfordert, die vom Pfad der Benutzerbewegung abhängt und nicht nur von den Endpunkten.

Stufe A. Beachten Sie, was fehlt: jede Erwähnung einer bestimmten Taste.

Das Understanding-Dokument ist dazu eindeutig:

Schaltflächen mit Fokus lassen sich in der Regel sowohl mit der Eingabetaste als auch mit der Leertaste aktivieren. Wenn ein eigenes Schaltflächen-Steuer- element in einer Webanwendung stattdessen nur auf Enter reagiert (oder sogar auf eine völlig eigene Taste oder Tastenkombination), erfüllt dies dennoch die Anforderungen dieses Erfolgskriteriums.

„Enter hat nichts bewirkt, also 2.1.1" ist somit kein Befund. Ebenso wenig „dieses Element will eine Taste, die ich nicht erraten habe". 2.1.1 fragt, ob die Funktion überhaupt per Tastatur ausführbar ist — nicht, ob sie so ausführbar ist, wie Sie es erwartet haben.

Das schneidet in beide Richtungen. Es schließt eine Klasse falscher Positiver aus, bedeutet aber auch, dass ein Element 2.1.1 bestehen und trotzdem praktisch unbenutzbar sein kann, weil niemand die Taste findet. Das ist ein echtes Problem, gehört aber zu anderen Kriterien und zur schlichten Gebrauchstauglichkeit, nicht hierher.

Zweitens: drei Dinge, die unter 2.1.1 abgelegt werden und eigene Kriterien sind

Das ist wichtig, denn wenn ein Bericht alles unter einer Nummer ablegt, ist das bereits ein Hinweis darauf, wie er entstanden ist.

Steckenbleiben ist 2.1.2 Keine Tastaturfalle (A). Sie tabben hinein und nicht wieder heraus. Anderes Kriterium.

Sehen, wo man ist, ist 2.4.7 Fokus sichtbar (AA). Der dicke Fokusrahmen, den Sie beobachtet haben, ist Beleg für 2.4.7. Er belegt weder für noch gegen 2.1.1 — eine Seite kann auf jedem Element einen perfekten Fokusindikator haben und trotzdem an 2.1.1 scheitern, und sie kann 2.1.1 ohne jeden sichtbaren Fokus bestehen.

Ein von einer klebenden Kopfzeile verdeckter Fokus ist 2.4.11 Fokus nicht verdeckt (Minimum) (AA), neu in WCAG 2.2. Auch das ist nicht 2.1.1.

Wenn Ihr eigener Test aus „ich habe getabbt, den Fokus gesehen und Enter funktionierte" bestand, haben Sie gute Belege zu 2.4.7 gesammelt und nur teilweise Belege zu 2.1.1.

Wie ein echter 2.1.1-Befund aussieht

Ein Verstoß gegen dieses Kriterium muss eine Funktion benennen, die sich nicht ausführen lässt. Nicht ein Element, das existiert. Ein brauchbarer Befund enthält also:

• das Element und was Sie damit tun wollten
• die Schritte zur Reproduktion
• erwartetes gegen tatsächliches Ergebnis
• Browser, Betriebssystem und welche assistive Technologie in welcher Version

Das ist keine hohe Hürde. Es ist das, was die prüfende Person beim Testen notiert hat, weil sie es brauchte, um überhaupt festzustellen, dass etwas scheitert. Jede Prüfung, die ihr Geld wert ist, hat das bereits.

Wenn jedes Element denselben Befund trägt, ist das kein Ergebnis, sondern eine Vorlage. Eine einmal ausgefüllte und die Spalte hinunterkopierte Checkliste sieht genau so aus. Ebenso ein Bericht, in dem „nicht geprüft" als „fehlerhaft" exportiert wurde.

Fragen Sie für zwei oder drei markierte Punkte nach den Reproduktionsschritten. Das ist eine Tatsachenfrage, die man beantworten kann oder nicht, und sie klärt den Streit, ohne dass jemand über die Formulierung eines Erfolgskriteriums diskutieren müsste.

Aber schließen Sie nicht, Ihr eigener Test habe die Seite freigesprochen

Hier haben Leute, die beim Bericht recht behalten, anschließend oft unrecht bei ihrer eigenen Website.

Die Maus abzuziehen und Tab zu drücken ist ein echter Test — und er übersieht die meisten Fehler, die in Prüfungen tatsächlich auftauchen:

• Inhalt, der nur beim Überfahren mit dem Zeiger erscheint. Ihr Zeiger ist weg, Sie sehen ihn also nie, und Tastaturnutzende auch nicht. (Verwandt: 1.4.13 Inhalt bei Hover oder Fokus, AA.)
• Alles, was Ziehen erfordert. Schieberegler, umsortierbare Listen, Kartenverschiebung. WCAG 2.2 hat 2.5.7 Ziehbewegungen (AA) genau deshalb ergänzt.
• Zusammengesetzte Widgets, bei denen Tab die Komponente erreicht, die Pfeile darin aber nie verdrahtet wurden. Eine eigene Listbox oder Registergruppe, in die man hineinkommt und in der man nicht navigiert.
• Modale Dialoge, die sich einwandfrei öffnen und ohne Zeiger nicht schließen lassen. Das ist 2.1.2 und der häufigste schwerwiegende Tastaturfehler, den ich sehe.
• Alles unterhalb einer Tastaturfalle, das Sie nie erreichen und dessen Fehlen in Ihren Notizen wie ein Bestehen aussieht.

Warum Sie beide recht haben können

Hier die Auflösung, die meistens zutrifft und die fast niemand prüft: Tastatur allein und Tastatur mit laufendem Screenreader sind zwei verschiedene Tests.

NVDA und JAWS fangen im Lesemodus Tastenanschläge ab, bevor die Seite sie erhält. Ein bei ausgeschaltetem Screenreader per Tab erreichbares Element kann im Lesemodus unerreichbar sein — und gelegentlich umgekehrt. Eine prüfende Person mit NVDA und eine entwickelnde Person ohne alles beobachten auf derselben Seite tatsächlich unterschiedliches Verhalten.

Wenn der Dienstleister also mit eingeschalteter assistiver Technologie geprüft hat und Sie ohne, lügt keiner von beiden und keiner hat das ganze Bild. Deshalb ist die Umgebungsangabe in einem Befund auch keine Bürokratie: Ohne sie lässt sich der Befund weder reproduzieren noch widerlegen.

Was zu tun ist, der Reihe nach

1. Fordern Sie Reproduktionsschritte für zwei oder drei markierte Punkte an.
2. Probieren Sie genau diese selbst mit laufendem NVDA im Lesemodus unter Windows. Firefox oder Chrome, je nachdem, was genannt wurde.
3. Lassen sie sich reproduzieren, haben Sie etwas Echtes über Ihre Seite gelernt.
4. Lassen sie sich nicht reproduzieren und der Dienstleister kann keine Schritte liefern, haben Sie Grund, die Spalte zurückzuweisen — und zu fragen, was im Bericht sonst noch so entstanden ist.

Ein automatischer Scanner, meiner eingeschlossen, klärt das nicht für Sie. Tastaturbedienbarkeit ist maschinell nicht zuverlässig feststellbar: Ein Werkzeug kann einen positiven tabindex melden, ein für assistive Technologie ausgeblendetes und dennoch fokussierbares Element oder ein Element ohne zugänglichen Namen — das ist wertvoll. Ob ein Mensch Ihre Kasse ohne Maus tatsächlich abschließen kann, bleibt eine Frage, die einen Menschen erfordert.

Der Vorbehalt

Ich beschreibe, wie man einen Bericht bewertet, und sage Ihnen nicht, dass Ihre Seite besteht. Wenn die Prüfung recht hat, macht schlechte Formulierung sie nicht falsch, sondern nur schlecht formuliert. Fordern Sie die Schritte an — und nehmen Sie dann ernst, was zurückkommt.

Quellen: Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility