Revision 718: WCAG: Pass, Fail oder kommt drauf an?

30. Juni 2026

Wir sprechen mit Patrick H. Lauke (LinkedIn, Mastodon, Bluesky) und Peter Krautzberger (LinkedIn, Mastodon) über die WCAG, ihre Success Criteria und die Frage, warum ein Standard, der auf den ersten Blick sehr eindeutig wirkt, in der Praxis oft viel Interpretationsspielraum lässt.

Wir sprechen darüber, warum WCAG 2.x trotz ihrer Schwächen weiterhin die Grundlage vieler Audits und gesetzlicher Anforderungen ist, wie sich neue Erfolgskriterien additiv an ältere anhängen, warum das nicht immer elegant ist und wie Patrick im WCAG-GitHub-Repository und der Backlog-Arbeit versucht, offene Fragen und Grauzonen besser zu klären.

Shownotes

[00:00:56] WCAG, Success Criteria und Interpretationsspielräume

Wir steigen mit Patricks und Peters Hintergrund ein: Patrick arbeitet bei Tetralogical im Accessibility Consulting, war früher bei Opera und ist unter anderem im W3C-Kontext aktiv. Peter arbeitet im akademischen Verlagswesen, ist in der ARIA Working Group und Co-Editor der ARIA-Spezifikation. Von dort aus landen wir bei der WCAG 2.2 und der Frage, wie belastbar ihre Erfolgskriterien eigentlich sind.

Patrick beschreibt die WCAG als Standard, der objektiv und binär wirkt, in der Praxis aber oft Interpretationsarbeit verlangt. Ein Kriterium kann formal nach Pass oder Fail aussehen, aber sobald man echte Interfaces, echte Nutzer:innen und echte Audit-Situationen betrachtet, entstehen Grauzonen. Besonders schwierig wird das, weil WCAG in Gesetze und Standards hineinreferenziert wird, etwa über den EAA, EN 301 549, BITV oder andere nationale Regelungen. Damit hängen an der Auslegung nicht nur Best Practices, sondern auch Compliance, Haftungsfragen und wirtschaftlicher Druck.

Ein erstes Beispiel ist 1.1.1 Non-text Content: Alle wissen, dass Bilder, Audiohinweise oder andere Nicht-Text-Inhalte Alternativen brauchen, aber was eine „gute“ Alternative ist, hängt stark vom Kontext ab. Ist ein Speaker-Foto dekorativ, wenn der Name danebensteht? Oder gehört eine Beschreibung des Aussehens dazu? Schon hier zeigt sich, dass selbst das erste Erfolgskriterium nicht rein mechanisch prüfbar ist.

Weiter geht es mit Target Size aus WCAG 2.1 und 2.2. Patrick erklärt, dass die Formulierung theoretisch sogar einen ein Pixel großen Link bestehen lassen kann, wenn rundherum genug Abstand vorhanden ist. Das wäre formal eventuell ein Pass, praktisch aber ein schlechtes Interface. Genau solche Fälle zeigen, dass man WCAG nicht als vollständige Usability-Spezifikation missverstehen sollte.

Ein weiterer großer Block dreht sich um das additive Modell von WCAG 2.x. Ältere Success Criteria werden in Minor-Versionen nicht grundlegend umgeschrieben, damit neuere Fassungen rückwärtskompatibel zu bestehenden gesetzlichen Referenzen bleiben. Stattdessen kommen neue Kriterien hinzu. Das erklärt Überschneidungen wie zwischen Pointer Gestures und Dragging Movement. Patrick beschreibt, wie er in den nicht-normativen Understanding-Dokumenten Beispiele und Erklärungen verschoben und präzisiert hat, ohne den normativen Kern der Spezifikation umzudeuten.

Wir sprechen außerdem über Reflow und die Frage, wie sinnvoll sehr konkrete Grenzwerte wie 320 CSS Pixel sind. Die Idee dahinter ist klar: Inhalte sollen bei starkem Zoom nicht in zwei Richtungen gescrollt werden müssen. In der Praxis entstehen aber neue Fragen, etwa was bei 319 oder 321 Pixeln gilt, wie man Apps auditiert und wie man WCAG auf Nicht-Web-Kontexte überträgt. Dazu verweisen wir auf die Mobile Accessibility Task Force und WCAG2ICT.

Auch die Terminologie kommt zur Sprache: WCAG 2.x denkt noch stark in „Pages“, was bei Single-Page-Apps, App-Screens und dynamischen Views immer weniger passt. In Richtung WCAG 3 und im Kontext von WCAG-EM wird deshalb stärker über Views und Screens gesprochen. Patrick schätzt WCAG 3 zwar als wichtig und konzeptionell interessant ein, hält es aber für realistischer, die heute verwendete WCAG 2.x weiter zu schärfen, weil sie die aktuelle Audit- und Gesetzesrealität prägt.

Zum Schluss sprechen wir darüber, wie man sich einbringen kann. Die Arbeit an WCAG läuft öffentlich über GitHub, Issues und Pull Requests können verfolgt und eingebracht werden. Patrick verweist auch auf das öffentliche WCAG 2 Backlog Project Board, über das offene Themen sortiert und abgearbeitet werden.