Warum selbst staatliche Webseiten regelmäßig Accessibility-Probleme haben, was automatisierte Tests tatsächlich abdecken und wo die Grenze zwischen belastbarer Analyse und Übertreibung liegt.
Wer beginnt, Webseiten automatisiert auf Accessibility-Probleme zu prüfen, macht schnell eine irritierende Beobachtung: Ministerien, Universitäten, Kommunen, Bahnportale und Krankenkassen zeigen regelmäßig dieselben Fehler wie kleine Unternehmenswebseiten ohne Budget für barrierefreie Entwicklung. Fehlende Alt-Texte, unzureichende Kontraste, Formulare ohne Labels, ARIA-Attribute die nichts bewirken, Linktexte wie „Mehr” oder „Hier klicken” — Textqualität, die auch bei strukturiertem Schreibprozess für Webseiten regelmäßig thematisiert wird.
Das ist kein Zeichen, dass das Tool falsch liegt. Es ist ein Abbild der Realität.
Vier Ebenen, die man trennen muss
Wenn es um Accessibility geht, werden vier Dinge regelmäßig durcheinandergeworfen:
Gesetzliche Pflicht — In Deutschland gilt seit 2025 das Barrierefreiheitsstärkungsgesetz (BFSG), das auf der EU-Richtlinie 2019/882 basiert. Für öffentliche Stellen gilt die BITV 2.0 bereits länger. Eine gesetzliche Pflicht bedeutet aber nicht, dass alle Betroffenen tatsächlich konform sind.
Tatsächliche WCAG-Konformität — WCAG 2.1 AA ist der verbreitete Referenzstandard. Vollständige Konformität ist kein Prozentwert, sondern ein binärer Status: Entweder alle relevanten Erfolgskriterien sind erfüllt oder nicht. Dieser Status ist ohne umfangreiches manuelles Audit praktisch nicht feststellbar.
Automatisiert messbare Kriterien — Nur etwa 20–40 % der WCAG-Erfolgskriterien lassen sich überhaupt automatisiert prüfen. Ob ein Alt-Text sinnvoll ist, ob die Lesereihenfolge für Screenreader stimmt, ob ein Dialog tatsächlich bedienbar ist — das erfordert menschliches Urteil.
Formal korrekt vs. praktisch nutzbar — Eine Seite kann technisch valide Landmark-Rollen setzen und trotzdem für Screenreader-Nutzer schwer navigierbar sein. HTML-Korrektheit und tatsächliche Bedienbarkeit sind nicht dasselbe.
Was automatisierte Tools wirklich finden
Die 20–40 % automatisiert prüfbarer Kriterien klingen nach wenig. In der Praxis sind das aber genau die Fehler, die am häufigsten auftreten und am leichtesten vermeidbar wären:
- Bilder ohne Alt-Attribut oder mit leeren Alt-Texten
- Formularfelder ohne zugeordnetes Label
- Kontrastverhältnisse unter den WCAG-Schwellenwerten (4,5:1 für normalen Text)
- Buttons und Links ohne zugänglichen Namen
- Heading-Hierarchien die übersprungen werden (h1 → h3 ohne h2)
- ARIA-Rollen und -Attribute die falsch oder widersprüchlich gesetzt sind
- Frames ohne Title-Attribut
- Sprach-Attribut fehlt im HTML-Element
Wenn diese Grundlagen auf einer Seite massenhaft fehlen, ist das aussagekräftig — auch wenn die Liste damit nicht vollständig ist.
Warum auch große Organisationen diese Fehler haben
Barrierefreiheit ist rückwirkend teuer. Eine Seite, die über zehn Jahre in einem CMS gewachsen ist, mit wechselnden Redaktionsteams und ohne technische Accessibility-Anforderungen im Entwicklungsprozess, akkumuliert solche Fehler systematisch. Kein einzelner Entwickler baut bewusst leere Buttons ein — aber über hunderte Seitenaktualisierungen verteilt entstehen sie trotzdem.
Viele Organisationen befinden sich im Zustand „Wir bemühen uns und haben eine Erklärung zur Barrierefreiheit veröffentlicht” – nicht im Zustand „Wir sind WCAG AA konform”. Die Erklärung zur Barrierefreiheit ist eine gesetzliche Anforderung. Konformität ist eine technische.
Ergebnisse validieren, bevor man kommuniziert
Automatisierte Ergebnisse sind nur so wertvoll wie ihre Nachvollziehbarkeit. Drei Schritte, die Belastbarkeit herstellen:
Gegen etablierte Tools benchmarken. axe DevTools, WAVE, Lighthouse und Accessibility Insights prüfen nach unterschiedlichen Regelsätzen. Identische Scores sind nicht zu erwarten — aber dieselben strukturellen Probleme sollten auftauchen. Wenn ein Tool konsequent Fehler findet, die andere ignorieren, ist das erklärungsbedürftig. Wenn die Schnittmenge groß ist, ist das ein gutes Zeichen.
Manuelle Stichproben auf 20 Findings. Für jeden gefundenen Fehler: Ist das tatsächlich ein WCAG-Verstoß? Gegen welches Erfolgskriterium? Ist es kritisch oder formal? Diese Überprüfung liefert eine belastbare Einschätzung von False-Positive-Rate und Vertrauensniveau — und zeigt, wo ein Tool besonders präzise oder ungenau arbeitet.
WCAG-Mapping dokumentieren. Jede Prüfregel sollte einem konkreten Erfolgskriterium zugeordnet sein:
| Prüfung | WCAG |
|---|---|
| Fehlender Alt-Text | 1.1.1 Nicht-Text-Inhalt |
| Kontrast zu gering | 1.4.3 Kontrast (Minimum) |
| Fehlendes Label | 3.3.2 Beschriftungen |
| Leerer Button | 4.1.2 Name, Rolle, Wert |
Dieses Mapping macht Ergebnisse überprüfbar und verhindert, dass Scoring-Zahlen wie eine Blackbox wirken.
Wie man Ergebnisse kommuniziert, ohne zu übertreiben
Der wichtigste Unterschied in der Kommunikation liegt zwischen Urteil und Beobachtung.
Problematisch sind Formulierungen wie „nicht barrierefrei”, „nicht WCAG-konform”, „illegal” oder Prozentwerte für „WCAG-Konformität” — denn das impliziert eine vollständige Bewertung, die automatisierte Tests nicht leisten können. Eine Aussage wie „Bundestag.de erreicht nur 62 % WCAG-Konformität” ist technisch nicht haltbar und angreifbar.
Belastbar und präzise sind Formulierungen wie:
- „automatisiert erkennbare Accessibility-Probleme”
- „maschinell prüfbare WCAG-Kriterien”
- „technische Voranalyse auf automatisiert identifizierbare Verstöße”
- „Hinweise auf potenzielle Probleme nach WCAG 2.1”
Ein Hinweis, der immer sichtbar sein sollte: „Diese Analyse basiert ausschließlich auf automatisiert prüfbaren Kriterien und ersetzt kein vollständiges manuelles WCAG-Audit.” Dieser Satz schützt fachlich und macht die Einschränkungen transparent — was paradoxerweise Vertrauen schafft statt es zu beschädigen.
Der strategische Wert von Benchmark-Daten
Wer viele Seiten systematisch prüft, gewinnt etwas, das wertvoller ist als einzelne Auditergebnisse: vergleichbare Messdaten.
Aussagen wie „In 80 % der geprüften Behördenseiten fehlen Kontrastwerte nach WCAG 1.4.3” oder „Fehlende Formular-Labels sind der häufigste automatisiert erkennbare Fehler” sind datengetrieben und ohne Übertreibung formulierbar — vorausgesetzt, die Datenbasis ist groß genug und die Methodik dokumentiert.
Das unterscheidet sich grundlegend von einem Einzelaudit. Nicht eine Seite bekommt eine Note, sondern ein Marktausschnitt wird messbar. Für Agenturen, Entwickler und Organisationen, die wissen wollen, wo sie im Vergleich stehen, ist das ein anderer Gesprächseinstieg als „Hier ist eine Fehlerliste”.
Einordnung
Automatisierte Accessibility-Tools haben einen schlechten Ruf — meistens zu Unrecht. Dass sie nur 20–40 % der WCAG-Kriterien abdecken, bedeutet nicht, dass die Ergebnisse wertlos sind. Es bedeutet, dass man präzise kommunizieren muss, was gemessen wurde.
Der eigentliche Mehrwert entsteht nicht durch die Fehlerliste, sondern durch Gewichtung, Priorisierung und Vergleichbarkeit. Wer Ergebnisse transparent macht, das Mapping zu WCAG-Kriterien dokumentiert und den Unterschied zwischen automatisierter Vorprüfung und vollständigem Audit klar benennt, ist glaubwürdiger als Tools, die vollständige Konformitätsbewertungen versprechen. Accessibility-Probleme auf öffentlichen Webseiten zu dokumentieren ist grundsätzlich legitim — die Qualität der Kommunikation entscheidet darüber, ob es nützlich oder kontraproduktiv wirkt. Wer außerdem verstehen will, wie Suchmaschinen eine Seite wahrnehmen und indexieren, findet im Google-Indexierungs-Diagnose-Workflow einen ergänzenden Ausgangspunkt.