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

#a11y #wcag #webdev #wordpress

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.

Regel	Angegeben	Tatsächlich
Doppelte IDs	4.1.1	Aus den WCAG 2.2 entfernt
Ein `main`-Landmark	1.3.6 AAA	1.3.6 ist Identify Purpose, ein anderes Kriterium
Sprache von Textteilen	3.1.2 AA	3.1.2 ist Stufe A — und die Prüfung tat nicht, was ihr Titel versprach
Nichtssagender Linktext	2.4.4	2.4.4 wird durch den Kontext erfüllt
Übersprungene Überschriftenebenen	1.3.1	Die WCAG verlangen keine fortlaufenden Ebenen
Fehlendes `h1`	1.3.1	Empfohlene Praxis
Leere Überschrift	1.3.1	Empfohlene Praxis
Positiver `tabindex`	2.4.3	Empfohlene Praxis

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.