Was der automatisierte Barrierefreiheits-Scan prüft – und was nicht

Der Satz „Wir haben doch ein Tool, das piept schon, wenn was fehlt“ stimmt nur zur Hälfte. Automatisierte Prüfungen sind der schnellste Weg zu einer ersten Befundliste, aber sie decken nur die Kriterien ab, die sich maschinell entscheiden lassen. Dieser Beitrag legt offen, welche Prüfungen BarriereRadar automatisiert durchführt, warum andere Kriterien Menschen brauchen und wie Sie beides sinnvoll kombinieren.

Was ein automatisierter Scan leisten kann

Maschinell prüfbar ist, was sich aus dem Quelltext eindeutig entscheiden lässt: Fehlt ein Attribut? Ist eine Beschriftung verknüpft? Ist das Kontrastverhältnis zweier Farben groß genug? Aus solchen Entscheidungen besteht der Regelkatalog von BarriereRadar. Er ist eine flache Liste, und jede Regel trägt ihr Erfolgskriterium, eine Schwere und eine Fix-Anleitung. Welchem der vier WCAG-Prinzipien eine Regel zugehört, sagt die erste Ziffer ihres Erfolgskriteriums: 1 wahrnehmbar, 2 bedienbar, 3 verständlich, 4 robust. Nach dieser Ziffer sind die Beispiele hier geordnet:

Die dritte Spalte ist ein Auszug und keine Aufzählung. Den vollständigen Katalog führen die App und die Produktseite unter Was geprüft wird, mit Kriterium, WCAG-Fundstelle und Schwere je Regel. Beide holen ihn beim Laden aus derselben Schnittstelle; deshalb steht er hier nicht abgetippt, denn eine Abschrift wäre beim nächsten Ausbau des Katalogs still veraltet. Daneben steht dort mit Begründung, was der Scan ausdrücklich nicht entscheidet.

Das Ergebnis ist eine priorisierte Befundliste: kritisch zuerst, mit einer konkreten Fix-Anleitung je Befund. Damit wird aus einem abstrakten Thema eine Aufgabenliste, die ein Entwicklungsteam abarbeiten kann. Wer sie von oben nach unten abarbeitet, beseitigt zuerst die Barrieren, an denen Nutzer heute ganz scheitern, und danach die, die das Angebot mühsam machen.

Die ehrliche Grenze: Was kein Scan entscheiden kann

Viele WCAG-Kriterien verlangen ein Urteil, das keine Maschine zuverlässig fällt. Drei Beispiele:

• Ob ein Alt-Text inhaltlich passt. Das Attribut kann da sein und trotzdem nutzlos sein („Bild1234.jpg“). Ob der Text das Bild sinnvoll beschreibt, kann nur ein Mensch beurteilen.
• Ob die Tastatur-Bedienung durchgängig funktioniert. Ein Scan erkennt entfernte Fokus-Rahmen und positive tabindex-Werte. Ob sich der Shop komplett ohne Maus bedienen lässt, zeigt dagegen erst das eigene Durchtippen.
• Ob komplexe Widgets korrekt ausgezeichnet sind. Slider, Warenkorb-Overlays oder Filterdialoge brauchen ARIA-Muster, deren Korrektheit sich nicht aus dem bloßen Vorhandensein von Attributen ablesen lässt.

Warum Overlays die Antwort nicht sind

Overlay-Widgets versprechen, Barrierefreiheit nachträglich „über die Seite zu legen“: ein Schalter für Kontraste, eine Vorlesefunktion, größere Schrift. An den Barrieren im Quelltext ändert das nichts. Fehlende Alt-Texte, unbeschriftete Formularfelder und eine zerstörte Überschriftenstruktur bleiben bestehen, und Screenreader-Nutzer bekommen die Fehler weiterhin zu spüren.

Die Pflicht aus § 14 BFSG richtet sich an das Angebot selbst: Die Dienstleistung muss die Barrierefreiheitsanforderungen erfüllen. Ein Overlay ersetzt weder die Beseitigung der Mängel noch die Erklärung zur Barrierefreiheit. Dokumentiert wird damit ebenfalls nichts: Wer nach dem geprüften Stand gefragt wird, steht mit einem Widget genauso ohne Beleg da wie vorher.

Der sinnvolle Ablauf in der Praxis

Die wiederkehrende Prüfung ist dabei kein Selbstzweck: § 14 Abs. 3 BFSG verlangt, dass die Anforderungen stets erfüllt werden, also auch nach dem Redesign, dem Plugin-Update oder der neuen Checkout-Erweiterung.

Häufige Fragen

Wie viel Prozent der WCAG deckt ein automatisierter Scan ab?

Eine seriöse Prozentzahl gibt es nicht, denn sie hängt davon ab, wie man zählt. Klar ist nur: Ein Teil der Kriterien ist maschinell entscheidbar (fehlende Attribute, verknüpfte Labels, Kontrastrechnung), ein anderer Teil verlangt menschliches Urteil. Deshalb nennen wir keine Zahl, sondern die konkrete Liste dessen, was der Scan prüft: Sie steht in der App und auf der Produktseite und wird dort aus dem laufenden Regelkatalog geladen, nicht abgetippt.

Mein Scan zeigt keine Befunde. Bin ich fertig?

Nein. Ein Scan ohne Befunde sagt nur etwas über die automatisierbar prüfbaren Kriterien aus. Ergänzen Sie mindestens einen Tastatur-Test und eine Stichprobe mit Screenreader, und wiederholen Sie die Erstprüfung nach jeder größeren Änderung an der Website. Erst beides zusammen trägt eine belastbare Aussage über den Stand Ihres Angebots.

Prüft BarriereRadar auch den Kontrast meines ganzen Designs?

Der Kontrast-Check deckt Inline-Farbangaben ab, bei denen Text- und Hintergrundfarbe zusammen am selben Element stehen. Dort rechnet er das WCAG-Verhältnis exakt nach. Farben aus Stylesheets gehören in den vollständigen Test; genau diese Grenze steht auch in der Regelbeschreibung.

Ersetzt die Erstprüfung eine Fachberatung?

Nein. Die Erstprüfung dokumentiert den automatisierbaren Teil und gibt Fix-Anleitungen an die Hand. Sie ist keine Rechtsberatung und ersetzt keinen vollständigen WCAG-Test durch Fachleute. Maßgeblich sind BFSG, BFSG-Verordnung und die Norm EN 301 549 in ihrer aktuellen Fassung.

Das Wichtigste in Kürze

Dieser Beitrag ersetzt keine Rechtsberatung. Eine automatisierte Erstprüfung ersetzt nicht den vollständigen BITV-/WCAG-Test – maßgeblich sind BFSG, BFSG-Verordnung und die harmonisierte Norm EN 301 549 in ihrer aktuellen Fassung.