Unser Prüfverfahren für Barrierefreiheit – und wo es endet

Reviseberg prüft Websites mit vier Arten von Nachweisen: automatisierten Regeln (axe-core) auf jeder gecrawlten Seite, einem Tastatur-Agenten, der echte Tasten drückt, Ergebnissen, die Menschen von Hand erfassen, und dokumentierten Entscheidungen Ihres Teams. Daraus erhält jedes WCAG-2.2-Erfolgskriterium der Stufen A und AA einen Status: bestanden, nicht bestanden, teilweise, ungeprüft oder nicht anwendbar. Was keine Maschine entscheiden kann, bleibt „ungeprüft“ – und wird nie still als „bestanden“ gezählt.

Diese Seite beschreibt, wie das im Detail funktioniert, wie der Score entsteht und wo automatisierte Barrierefreiheitsprüfung an ihre Grenzen kommt. Jede Zahl auf dieser Seite stammt aus demselben Code, mit dem das Produkt prüft und rechnet.

Das Prüfverfahren auf einen Blick

Schritt 1: Crawl und Regelprüfung mit axe-core

Reviseberg crawlt Ihre Website und führt auf jeder gefundenen Seite axe-core aus, die verbreitete Open-Source-Prüfbibliothek (derzeit Version 4.13.0). Geprüft wird nicht der Quelltext, sondern die gerenderte Seite in einem echten Browser – und zwar zweimal: bei 1.280 Pixel Breite mit allen Regeln für WCAG 2.2 A und AA, und bei 360 Pixel noch einmal mit den Regeln, die erst scheitern, wenn das Layout umbricht: color-contrast, target-size, meta-viewport und scrollable-region-focusable. Alles doppelt zu prüfen, würde dieselben Markup-Fehler zweimal melden. Diese Regeln doppelt zu prüfen, findet die Kontraste, Zielgrößen und Überläufe, die ein Smartphone tatsächlich zeigt.

axe-core kennt neben „Verstoß“ und „bestanden“ ein drittes Ergebnis: Fälle, in denen eine Regel nicht sicher entscheiden kann, etwa Text über einem Hintergrundbild. Diese Fälle landen in der Liste „Potenzielle Probleme“, wo ein Mensch entscheidet. Wir melden sie weder als Fehler noch als bestanden, und sie kosten keine Punkte.

Gleiche Verstöße fassen wir zu einem Issue zusammen: eine Regel, die betroffenen WCAG-Kriterien, die Zahl der Vorkommen und Seiten. Ein Issue gilt als behoben, wenn seine Befunde bei einem neuen Crawl nicht mehr auftreten – nicht, wenn jemand einen Haken setzt. Einen Status „erledigt“ gibt es deshalb nicht.

Schritt 2: Der Tastatur-Agent

Regeln sehen nur einen Zustand der Seite. Ob man eine Seite mit der Tastatur bedienen kann, zeigt sich erst beim Bedienen. Deshalb geht unser Tastatur-Agent die Seiten, die Sie als Nutzerreise angeben – etwa vom Warenkorb bis zur Kasse – mit Tab, Umschalt+Tab und Escape durch. Er steuert Chromium mit echten Tastenereignissen, nie mit einem gescripteten Fokus-Aufruf: Der würde Elemente erreichen, die die Tab-Reihenfolge nicht erreicht, und genau diese Lücke ist der Fehler, den wir suchen.

Er meldet Elemente, die sich wie Bedienelemente verhalten, aber von keinem Tab erreicht werden, Fokus auf Elementen ohne Größe oder außerhalb des Bildschirms, Fokus ohne sichtbare Veränderung, fehlende Skip-Links und Tastaturfallen. Eine Falle nennt er erst dann Falle, wenn Tab, Umschalt+Tab und Escape sie bestätigt haben. Zu jedem Schritt speichert er einen Pfad als Nachweis: gedrückte Taste, fokussiertes Element mit Rolle und Namen, Urteil mit Begründung und bei Fehlern einen Screenshot. Wo die Stile nicht eindeutig zeigen, ob ein Fokus sichtbar ist, lautet das Urteil „Mensch“ statt einer Behauptung.

Heute läuft genau dieser eine Agent. Weitere Agenten (Screenreader, Zoom und Reflow, Formulare, Sprachsteuerung u. a.) sind in Entwicklung, auf der Agenten-Seite als solche gekennzeichnet und fließen in keinen Status ein.

Schritt 3: Ein Status für jedes WCAG-Kriterium

Aus Regeln, Agent, manuellen Ergebnissen und Entscheidungen berechnen wir für jedes der 55 Erfolgskriterien von WCAG 2.2 (A und AA) einen Status:

• Bestanden: kein offener Verstoß, und entweder entscheidet eine automatische Prüfung das Kriterium vollständig, oder ein Mensch hat ein Bestehen erfasst.
• Nicht bestanden: mindestens ein offener Verstoß. Ein Crawl, der einen Verstoß findet, sticht ein manuell erfasstes „bestanden“ – dann widersprechen die Belege dem Haken.
• Teilweise: Die automatischen Prüfungen haben nichts gefunden, decken aber nur einen Teil des Kriteriums ab. Der Rest braucht ein menschliches Urteil.
• Ungeprüft: Keine automatische Prüfung erreicht das Kriterium, und es liegt kein gültiges menschliches Ergebnis vor.
• Nicht anwendbar: Der Inhaltstyp kommt nicht vor (z. B. keine Videos) – das kann nur ein Mensch erfassen.

In unserer WCAG-2.2-Checkliste ist jedes Kriterium einer von drei Klassen zugeordnet: automatisch entscheidbar (4 Kriterien), teilweise automatisierbar (20) und nur manuell prüfbar (31). Nur eine Minderheit der Kriterien kann eine Maschine vollständig entscheiden.

Manche axe-core-Regeln prüfen gar kein Erfolgskriterium, sondern eine bewährte Praxis – Landmarks, Überschriftenhierarchie, eine Seite ohne h1. Solche Befunde zeigen wir, weil sie echte Hürden sind, aber als Best Practice: Sie lassen kein Kriterium scheitern, erscheinen nicht in der Erklärung und kosten im Score weniger als ein WCAG-Verstoß (siehe unten).

Warum „ungeprüft“ nie „bestanden“ ist

Viele Scanner zeigen am Ende eine grüne Zahl, obwohl sie die Hälfte der Anforderungen gar nicht angesehen haben. Ein leeres Feld liest sich dann wie ein Bestehen. Das ist bequem, aber falsch – und es wird teuer, wenn eine Erklärung zur Barrierefreiheit darauf aufbaut. Wenn ein Scanner ein rein manuelles Kriterium als bestanden meldet, meldet er in Wahrheit, dass er nicht hingesehen hat. Deshalb zeigt Reviseberg offen, wie viele Kriterien ungeprüft sind, und die Erklärung zur Barrierefreiheit kann nur behaupten, was belegt ist. Solange Kriterien teilweise oder ungeprüft sind, lautet der Stand „teilweise konform“ – nie „vollständig konform“.

Schritt 4: Manuelle und geführte Prüfungen

Für Kriterien, die keine Automatisierung entscheiden kann, bietet Reviseberg zwei Wege, die zum selben Nachweis führen:

• Manuelle Prüfung: Eine fachkundige Person erfasst ein Ergebnis – etwa zu 1.2.2 Untertitel oder 1.3.2 Bedeutungstragende Reihenfolge. Die Methode ist Pflicht („NVDA + Firefox“, „nur Tastatur“), und ein „nicht bestanden“ muss sagen, was scheitert.
• Geführte Prüfung: Für jedes der 31 Kriterien, die kein Crawl erreicht, gibt es eine Schritt-für-Schritt-Anleitung: wann das Kriterium überhaupt gilt, was zu tun ist, worauf zu achten ist und was als Verstoß zählt. Geschrieben für Menschen, die kompetent, aber keine Barrierefreiheits-Spezialisten sind.

Jedes erfasste Ergebnis trägt Person und Datum, wird nie überschrieben, sondern nur ergänzt, und läuft nach 12 Monaten ab. Websites ändern sich; ein Urteil von vor zwei Jahren ist kein Nachweis für heute. Ein abgelaufenes Ergebnis bleibt im Verlauf sichtbar, das Kriterium fällt aber auf „ungeprüft“ zurück, und der Status in Bericht und Erklärung passt sich an.

Wie der Score berechnet wird

Der Barrierefreiheits-Score beantwortet eine Frage: Wie viele und wie schwere automatisch gefundene Barrieren sind gerade offen? Er beginnt bei 100, und jedes offene Issue zieht genau die Punkte ab, die seine Behebung zurückbringt:

• Punkte zurück = 7,4 × Schweregrad × WCAG-Stufe × Reichweite
• Score = 100 − Summe der Punkte zurück aller offenen Issues, gerundet und nie unter 0

Ein Best-Practice-Befund wiegt weniger als ein Verstoß der Stufe AAA: Er ist eine echte Hürde, aber ein Rat des Werkzeugs, keine Anforderung, die das W3C aufgeschrieben hat. Die Reichweite wächst logarithmisch: Ein Template-Fehler auf jeder Seite wiegt mehr als ein Einzelfall, aber nicht tausendmal mehr. Ab 1.400 Vorkommen wächst sie nicht weiter.

Für jedes Issue zeigen wir die Punkte zurück, und danach ist die Issue-Liste sortiert – so sehen Sie, was pro Arbeitsstunde am meisten bewirkt. Ein Beispiel: „Fokus nicht sichtbar“ (2.4.7, AA, schwerwiegend) mit 17 Vorkommen bringt 3,42 Punkte zurück.

Jeder gespeicherte Score trägt die Version der Formel, derzeit v2. Ändert sich eine Gewichtung, ändert sich die Version – v2 etwa hat Best-Practice-Befunde von Stufe A auf ihr eigenes, geringeres Gewicht gesetzt – so zeigt ein Verlauf, wo sich die Formel bewegt hat, statt so zu tun, als hätte sich die Website bewegt. Qualität (defekte Links, Rechtschreibung, Lesbarkeit) und SEO werden getrennt bewertet, mit derselben Rechnung ohne WCAG-Stufe; sie bewegen den Barrierefreiheits-Score nie.

Wichtig: Der Score ist keine Konformitätsaussage. Eine Website mit Score 100 kann trotzdem Kriterien verfehlen, die nur ein Mensch prüfen kann. Deshalb steht neben dem Score immer die Kriterienübersicht mit allen „ungeprüft“- und „teilweise“-Einträgen.

Entscheidungen mit Begründung

Nicht jeder Befund ist korrekt oder sofort lösbar. Ihr Team kann Befunde als Fehlalarm, ignoriert oder nicht behebbar markieren – für ein Element, eine Seite oder die ganze Website, auf Wunsch bis zu einem Datum, und immer mit Begründung. Wer wann entschieden hat, wird gespeichert; ein Betrachter ohne Bearbeitungsrechte kann keine Entscheidung erfassen.

Ein so entschiedener Befund kostet keine Punkte mehr und lässt sein Kriterium nicht mehr scheitern. Genau deshalb ist die Begründung Pflicht: Die Entscheidung ist Teil des Nachweises, nach dem eine Prüferin als Erstes fragen wird.

Zuordnung zu EN 301 549 und BITV-Test

EN 301 549 ist die europäische Norm für barrierefreie Informations- und Kommunikationstechnik. Ihr Kapitel 9 (Web) übernimmt die WCAG-Erfolgskriterien in eigener Nummerierung: Aus WCAG 2.1.1 „Tastatur“ wird Abschnitt 9.2.1.1. Reviseberg berichtet deshalb aus denselben Kriterien auch Abschnitt für Abschnitt nach EN 301 549 V3.2.1 ^[2].

V3.2.1 beruht auf WCAG 2.1. Die in WCAG 2.2 neuen Kriterien – 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 und 3.3.8 – haben dort keinen Abschnitt und erscheinen bei uns als WCAG-Ergebnisse ohne Abschnittsnummer. Im September 2026 hat ETSI die Fassung V4.1.1 veröffentlicht, die WCAG 2.2 übernimmt ^[3][4]. Auf sie ist unser Bericht noch nicht umgestellt.

Viele deutsche Prüfer arbeiten mit dem BIK BITV-Test, der Anforderungen in feinere Prüfschritte zerlegt ^[5]. Reviseberg ordnet seine Befunde diesen Prüfschritten nicht zu. Ein BITV-Test ist eine manuelle Expertenprüfung; Reviseberg ersetzt ihn nicht, sondern deckt ab, was sich automatisieren lässt, und hält die Belege zwischen zwei Audits aktuell.

Grenzen der automatisierten Prüfung

Wir sagen offen, was unsere Automatisierung nicht leistet:

• Bedeutung: Ob ein Alternativtext, eine Überschrift oder ein Linktext inhaltlich passt, entscheidet ein Mensch. KI-Vorschläge für Alternativtexte gibt es – übernommen wird nur, was eine Person annimmt, und angewendet wird nichts automatisch.
• Verständlichkeit: Qualität von einfacher Sprache und redaktionelle Absicht.
• Medien: Qualität von Untertiteln, Audiodeskription und Gebärdensprache.
• Echte Transaktionen: Abläufe mit echter Zahlung oder echten Ausweisdokumenten.
• Assistive Technik: Wie ein Screenreader die Seite tatsächlich vorliest, prüft heute kein Agent. Der Screenreader-Agent ist in Entwicklung.
• Dokumente: Verlinkte PDFs Ihrer Website prüfen wir nur auf ihre Struktur: ob sie getaggt sind, ob die Tags Inhalt tragen, Dokumentsprache, einen angezeigten Titel und Alternativtexte von Abbildungen. Ob die Lesereihenfolge stimmt, Tabellen, Kontrast und Formularfelder in PDFs prüfen wir nicht; Office-Dateien öffnen wir nicht.
• Rechtliche Freigabe: Die Erklärung zur Barrierefreiheit verantworten Sie; wir sind keine Kanzlei.

Kostenlos prüfen und den Status Ihrer Kriterien sehen

Wer hinter der Methodik steht

Keivan Sina arbeitet seit 2013 als UX-Designer und Frontend-Entwickler und prüft seit Jahren Websites nach WCAG, BITV und BFSG für Agenturkunden aus Tourismus, öffentlichem Sektor und Hafenwirtschaft. Die Methodik oben ist die Art, wie er selbst prüfen würde – nur mit jeder Seite statt einer Stichprobe. Fragen oder Einwände zur Methodik: hello@reviseberg.com.

Änderungen an der Methodik

Ändert sich eine Gewichtung, die Zuordnung eines Kriteriums oder die Status-Logik, steht es hier – mit Datum und der Score-Version, ab der es gilt.