Ein Prüfer fand drei falsche WCAG-Kriterien in meinem Barrierefreiheits-Plugin. Ich habe nachgesehen und acht gefunden.

Ich entwickle einen Barrierefreiheitsscanner für WordPress. Vergangene Woche hat ihn der Prüfer eines Marktplatzes zurückgewiesen, unter anderem mit dieser Begründung:

Die Konformitätsregeln müssen korrigiert werden. „Sprache von Textteilen" validiert lediglich bereits vorhandene lang-Attribute und kann nicht ausgezeichnete fremdsprachige Passagen nicht erkennen; die Regel zum main-Landmark ist WCAG 1.3.6 Stufe AAA, wird aber als AA-Prüfung vermarktet; und doppelte IDs sollten nicht als WCAG-2.2-Verstoß unter 4.1.1 dargestellt werden.

Drei Feststellungen. Alle drei zutreffend. Was folgt, ist das, was geschah, als ich aufhörte, die drei zu beheben, und die übrigen zweiundzwanzig prüfte.

Die Regel, die es nicht mehr gibt

Ich beginne mit der dritten, weil sie am leichtesten zu überprüfen und am weitesten verbreitet falsch ist.

Das Erfolgskriterium 4.1.1 Parsing wurde aus den WCAG 2.2 entfernt. Nicht abgeschwächt, nicht als veraltet markiert — entfernt. Die W3C-Empfehlung führt es im Konformitätsabschnitt als „Parsing (Obsolete and removed)". Es fiel weg, weil das, wovor es schützte — assistive Technik, die an fehlerhaftem Markup scheiterte — kein reales Fehlerbild mehr ist, seit Browser und Accessibility-APIs sich darauf geeinigt haben, wie fehlerhaftes HTML zu reparieren ist.

Mein Scanner meldete doppelte id-Attribute als WCAG-4.1.1-Verstoß. Gemessen an den WCAG 2.2 gibt es dieses Kriterium nicht mehr, gegen das man verstoßen könnte.

Doppelte IDs bleiben behebenswert. Sie zerstören label for-Zuordnungen und aria-labelledby-Verweise, sodass das falsche Element angesagt wird — oder gar keines. Aber das ist ein 4.1.2-Problem, wenn es tatsächlich einen zugänglichen Namen zerstört, und das zu erkennen ist eine andere Prüfung als das Zählen doppelter IDs. Was ich hatte, war eine allgemeine Doppel-ID-Prüfung, die die Nummer eines zurückgezogenen Kriteriums trug.

Dann habe ich den Rest geprüft

Der Prüfer hatte drei gefunden. Ich hätte drei beheben können. Stattdessen habe ich alle 25 Regeln genommen und jede einzelne gegen die WCAG-2.2-Empfehlung geprüft — und dagegen, wie axe-core die entsprechende Regel einordnet. Denn axe-core ist die Referenzimplementierung, auf der ein Großteil dieser Branche aufbaut, und sie trifft eine Unterscheidung, die ich verloren hatte.

Acht Regeln waren falsch.

Einige davon verdienen einen Satz.

Nichtssagender Linktext. 2.4.4 heißt Link Purpose (In Context). Im Kontext. Ein Link mit der Beschriftung „Weiterlesen" erfüllt es, wenn der umgebende Absatz, Listenpunkt oder die Tabellenzelle das Ziel klar machen — was meistens der Fall ist. Das Kriterium, das verlangt, dass der Linktext für sich allein steht, ist 2.4.9, und es ist AAA. „Weiterlesen", über eine Seite hinweg wiederholt, ist also ein echtes Usability-Problem für jemanden, der sich per Tab durch Links bewegt — und kein Verstoß auf Stufe A.

Überschriftenebenen. Es gibt kein Erfolgskriterium, das verlangt, dass auf h1 ein h2 folgt. 1.3.1 Info and Relationships verlangt, dass visuell vermittelte Struktur programmatisch verfügbar ist — Überschriften überhaupt zu verwenden ist die Art, wie man das erfüllt. Von h1 auf h3 zu springen ist unsauber und verschlechtert die Navigation mit Screenreadern, aber es ist nicht das, was 1.3.1 sagt. axe-core ordnet heading-order als empfohlene Praxis ein, und das seit Jahren.

Sprache von Textteilen. Diese war doppelt falsch. 3.1.2 ist Stufe A, nicht AA — ich hatte die Stufe falsch. Und die Prüfung trug den Titel „Fremdsprachige Passagen sollten ihre Sprache angeben", was etwas versprach, das keine automatische Prüfung leisten kann: zu wissen, dass eine Passage in einer anderen Sprache ist, wenn nichts sie kennzeichnet. Was der Code tatsächlich tat, war bereits vorhandene lang-Attribute zu validieren. Das ist eine nützliche Prüfung. Es ist nicht die Prüfung, die der Titel bewarb.

Wie lauten also die richtigen Zahlen

25 Prüfungen. Achtzehn entsprechen einem WCAG-2.2-Erfolgskriterium, verteilt auf vierzehn verschiedene Kriterien der Stufen A und AA: 1.1.1, 1.3.1, 1.3.5, 1.4.2, 1.4.3, 1.4.4, 2.4.1, 2.4.2, 2.4.4, 2.5.8, 3.1.1, 3.1.2, 3.3.2 und 4.1.2.

Sieben sind empfohlene Praxis. Behebenswert, aber keine Konformitätsverstöße.

Vor der Prüfung stand auf der Produktseite „25 automatische Prüfungen über die WCAG-2.2-Stufen A und AA" und 4.1.1 war unter den abgedeckten Kriterien aufgeführt. Beides war falsch, und das Zweite war für jeden nachprüfbar falsch, der die 2.2-Empfehlung gelesen hatte.

Warum das keine Erbsenzählerei ist

Hier kommt der Teil, der mich aufhören ließ, es als Etikettierungsproblem zu behandeln.

Das Plugin enthält einen Generator für die Barrierefreiheitsinformationen, die der European Accessibility Act verlangt. Er füllt den Abschnitt „bekannte Barrieren" aus dem letzten Scan vor und — das war das Verkaufsargument — hängt jeder Barriere das WCAG-Erfolgskriterium an.

Acht Regeln, die falsche, veraltete oder unpassende Kriterien nannten, schrieben diese Nummern also in ein Dokument, das der Websitebetreiber als rechtliche Erklärung über seinen eigenen Dienst veröffentlicht.

Eine Konformitätserklärung ist kein Bericht. Ein Bericht, der übertreibt, verdirbt einem den Nachmittag. Eine veröffentlichte Erklärung, die ein nicht existierendes Kriterium nennt, in einem Dokument, das man rechtlich pflegen muss, ist eine andere Kategorie von Fehler — und eine, die der Kunde entdeckt, nicht man selbst.

Das ist das Argument für die Unterscheidung, und es ist das einzige, das zählt. Ein Werkzeug, das jeden Befund als WCAG-Verstoß darstellt, bläht zwei Zahlen auf: die eigene — 25 WCAG-Prüfungen liest sich besser als 18 — und Ihre. Und Ihre aufgeblähte Zahl ist die, die öffentlich wird.

Was ich geändert habe

Jede Regel gibt nun an, was sie ist:

{
    id: 'heading_order',
    wcag: '',
    level: '',
    standard: 'best-practice',
    ...
}

Der Bericht nennt das Kriterium, wo es eines gibt, und Empfohlene Praxis, wo nicht — statt eines leeren WCAG ().

Der Generator verlangt jetzt zwei voneinander unabhängige Bedingungen, bevor er ein Kriterium in ein rechtliches Dokument schreibt: Die Regel muss als WCAG-zugeordnet markiert sein, und ihr Wert muss auf ^\d+\.\d+\.\d+$ passen. Jede der beiden allein hätte gereicht, um das Geschehene zu verhindern. Ich wollte diejenige, die überlebt, wenn jemand die andere bearbeitet.

Und die Marketingtexte sagen nun 18 und 7 — in der Readme, in der Dokumentation und im Marktplatz-Eintrag. Das war der unangenehmste Commit der Woche und derjenige, den ich wieder machen würde.

Wenn Sie eines dieser Werkzeuge bauen oder kaufen

Drei Fragen, die sich lohnen, und keine davon verlangt, mir zu glauben.

Meldet es noch 4.1.1? Dreißig Sekunden Prüfung, und Sie wissen, wann der Regelsatz zuletzt gegen den Standard gelesen statt von einem anderen Werkzeug kopiert wurde.

Unterscheidet es Erfolgskriterien von guter Praxis? Wenn jeder Befund eine Kriteriumsnummer trägt, sind zumindest einige dieser Nummern Dekoration. Die Referenzimplementierung, auf der diese Branche läuft, markiert rund ein Viertel ihrer Regeln als empfohlene Praxis. Ein Werkzeug ohne eine einzige ist nicht strenger, sondern unsorgfältiger.

Wohin geht das Kriterium nach dem Bericht? Fließt es in eine Erklärung, ein Siegel, ein PDF oder irgendetwas, das ein Kunde veröffentlicht, ist die Genauigkeit keine interne Qualitätsfrage mehr.

Was sich nicht geändert hat

Automatisierte Tests finden etwa ein Drittel der tatsächlichen Barrieren. Die Etiketten richtigzustellen verschiebt diese Zahl nicht. Ein sauberer Bericht ist ein gutes Zeichen, keine Konformitätserklärung, und Tests mit Tastatur und Screenreader durch einen Menschen bleiben der einzige Weg, es zu wissen.

Was die Prüfung verändert hat, ist enger und war, wie ich finde, die Woche wert: Wenn mein Werkzeug jetzt WCAG sagt, meint es das auch.