EAA-Prüfwerkzeuge: was automatische Tests finden und was sie nie finden werden
Wer nach einem „EAA-Prüfwerkzeug“ sucht, bekommt zwei sehr verschiedene Dinge mit demselben Namen. Das eine ist ein automatischer Scanner: Er durchsucht Ihre Seiten und meldet Fehler, die er messen kann. Das andere ist ein Overlay-Widget: eine Zeile JavaScript, die Konformität an einem Tag verspricht. Es ist nicht dasselbe Produkt, und nur eines davon ist wirklich nützlich.
Hier steht, was jedes davon tut und was keines für Sie tun kann.
Worauf das Gesetz verweist
Der European Accessibility Act, Richtlinie (EU) 2019/882 (in Deutschland umgesetzt durch das BFSG), gilt seit dem 28. Juni 2025. Er erfasst Produkte und Dienstleistungen, die an Verbraucher in der EU verkauft werden: E-Commerce, Bankdienstleistungen für Verbraucher, E-Books, Fahrkarten- und Check-in-Automaten, Verkehrsinformationen und mehr.
Hier stolpern viele. Der Act selbst enthält keine Liste mit Prüfpunkten. Er legt die Pflicht fest und verweist auf die harmonisierte Norm EN 301 549, die für Webinhalte wiederum auf WCAG 2.1 Stufe AA verweist. Wenn also jemand sagt „wir müssen den EAA bestehen“, dann wird gegen WCAG gemessen.
Der Act fügt Pflichten hinzu, zu denen WCAG nichts sagt: Sie müssen Informationen zur Barrierefreiheit Ihres Dienstes bereitstellen, verfügbar halten und erklären können, wie Sie die Anforderungen erfüllen. Ein perfektes Scanner-Ergebnis erzeugt dieses Dokument nicht.
Wo automatisches Scannen wirklich hilft
Scanner sind hervorragend in genau einer Sache: mechanische Fehler in Masse zu finden, auf Tausenden Seiten, in Minuten. Das ist nicht wenig. Wenn Sie 4.000 Produktseiten mit einem fehlenden Formular-Label in einer gemeinsamen Vorlage haben, findet ein Scanner es in einem Durchlauf und ein Mensch nie.
Was sie zuverlässig finden: fehlende alt-Attribute, Farbkontrast unter dem Grenzwert, Formularelemente ohne programmatisches Label, leere Links und Buttons, ein fehlendes lang-Attribut, kaputte Überschriftenfolgen, ungültige ARIA-Rollen und -Verweise.
Aber sie sehen nur, was sich mechanisch messen lässt. Jede ernsthafte Studie zu automatisierten Tests beziffert den so erkennbaren Anteil der WCAG-Fehler auf etwa ein Drittel. Nicht weil die Werkzeuge schlecht wären, sondern weil die meisten Barrieren mit Bedeutung zu tun haben, und Bedeutung kann ein Skript nicht lesen.
Ein Bild mit alt="image1234.jpg" besteht die Prüfung „hat Alternativtext“. Die eigentliche Anforderung verfehlt es komplett. Der Scanner sieht den Unterschied nicht; ein Mensch in zwei Sekunden.
Was kein Werkzeug für Sie entscheiden kann
- Ob der Alternativtext stimmt. Vorhandensein ist prüfbar, Richtigkeit nicht.
- Ob die Fokusreihenfolge Sinn ergibt. Eine Seite kann technisch fokussierbar sein, in einer unbrauchbaren Reihenfolge.
- Ob eine eigene Komponente per Tastatur funktioniert. Ihr Datumswähler, Ihr Mega-Menü, Ihr Dialog. Dort wohnen die echten Fehler.
- Ob eine Fehlermeldung hilft. „Ungültige Eingabe“ ist eine Fehlermeldung. Eine barrierefreie ist es nicht.
- Ob Untertitel zum Gesagten passen. Eine Untertiteldatei gibt es oder nicht. Ob sie stimmt, ist ein menschliches Urteil.
- Ob die Seite bei 200 % Zoom auf schmalem Bildschirm noch funktioniert, ohne abgeschnittene oder eingeschlossene Inhalte.
Zu Overlays
Overlay-Widgets verdienen eine klare Antwort, weil sie aggressiv verkauft werden und der Grund sind, warum viele überhaupt nach einem Prüfwerkzeug suchen.
Ein Overlay kann das HTML, das ein Screenreader liest, nicht reparieren. Es liegt darüber. In der Praxis berichten Nutzer assistiver Technologien, dass Overlays die Lage oft verschlechtern, weil sie Einstellungen und Verhalten stören, die der Nutzer bereits eingerichtet hat. Es gibt eine vielfach unterzeichnete Erklärung der Fachgemeinschaft dazu, und die Behörden haben Overlays nicht als Ersatz für Konformität anerkannt.
Wenn Ihnen ein Anbieter rechtliche Konformität per einzelnem Script-Tag verspricht, behandeln Sie das als die Behauptung, die es ist. Mehr dazu in warum ein Overlay Ihre Website nicht konform macht.
Wie ein funktionierender Prozess aussieht
- Zuerst den Scanner laufen lassen. Er ist billig, schnell und räumt das mechanische Rauschen ab, damit keine menschliche Zeit daran verloren geht. Lassen Sie ihn in der CI laufen, damit Rückschritte nicht zurückkehren.
- Einen Tastaturtest machen. Maus abziehen. Mit Tab Ihre fünf wichtigsten Nutzerwege von Anfang bis Ende durchgehen: Suche, Produkt, Warenkorb, Kasse, Konto. Wenn Sie einen Kauf nicht allein mit der Tastatur abschließen können, ist alles andere auf der Liste noch zweitrangig.
- Stichproben mit dem Screenreader. NVDA unter Windows oder VoiceOver unter macOS, auf denselben Wegen. Sie prüfen nicht alles, sondern ob die wichtigen Wege nutzbar sind.
- Die Barrierefreiheitserklärung schreiben. Was konform ist, was noch nicht, welche Alternative es gibt und wie man ein Problem meldet. Das ist eine gesetzliche Pflicht und zugleich das Dokument, das guten Willen zeigt, falls jemand fragt.
Kurz gesagt
Ein automatisches Werkzeug ist ein notwendiger Teil des Prozesses, aber nie der ganze. Es beseitigt die Fehler, die billig zu finden sind, damit Sie die teure menschliche Aufmerksamkeit auf die Fehler richten können, die Menschen wirklich an der Nutzung hindern.
Wer Ihnen das Ganze in einem Script-Tag verkauft, verkauft Ihnen den Teil, den es nicht gibt. Wenn Sie einen Ausgangspunkt möchten, zeigt Ihnen unser kostenloser Scan in Sekunden, wo Ihre Website steht.