Website auf Barrierefreiheit testen: Werkzeuge und Handprüfung
Eine Website testen Sie auf Barrierefreiheit in vier Schritten: automatischer Prüflauf, Bedienung nur mit der Tastatur, Kontraste und Zoom, dann ein Durchgang mit dem Screenreader. Maßstab sind die Erfolgskriterien der WCAG 2.2 in Stufe AA.
Ein Prüfwerkzeug meldet null Fehler, und trotzdem kommt niemand ohne Maus durch das Kontaktformular, weil der Absende-Knopf ein Bild ohne Text ist, das sich nur anklicken lässt. Solche Lücken findet nur, wer die Seite so benutzt wie Menschen, die auf Tastatur, Vergrößerung oder Sprachausgabe angewiesen sind. Ein Selbsttest kombiniert deshalb Werkzeuge mit Handprüfung.
Welche Websites nach dem Barrierefreiheitsstärkungsgesetz barrierefrei sein müssen, steht unter BFSG: Welche Websites seit Juni 2025 barrierefrei sein müssen; für Shops beschreibt Barrierefreiheitsstärkungsgesetz: Was Onlineshops umsetzen müssen die Pflichten im Kaufablauf. Wie Sie den Stand Ihrer Website selbst prüfen, steht in den fünf Schritten unten. Den Maßstab liefern die WCAG 2.2 des W3C: Stufe AA umfasst die Erfolgskriterien der Stufen A und AA.
Schritt 1 · Werkzeuge
Automatische Prüfwerkzeuge und ihre Grenzen
Drei Werkzeuge decken den automatischen Teil ab, alle kostenlos nutzbar:
axe: Die Prüfbibliothek axe-core von Deque läuft als Browsererweiterung und in vielen anderen Werkzeugen. Deque gibt an, dass sich damit im Durchschnitt 57 Prozent der WCAG-Probleme automatisch finden lassen. Wo axe sich nicht sicher ist, meldet es das Element als „incomplete“ zur Prüfung von Hand.
Lighthouse: In den Chrome-Entwicklertools eingebaut. Der Accessibility-Wert ist ein gewichteter Durchschnitt einzelner Prüfungen, jede bestanden oder nicht bestanden; die Gewichte stammen aus axe. Prüfungen, die Lighthouse nur zur Handprüfung auflistet, zählen nicht in den Wert.
WAVE: Das Werkzeug von WebAIM blendet Fehler, Warnungen und Strukturelemente direkt in die Seite ein, als Onlinedienst und als Browsererweiterung, auch für Seiten hinter einer Anmeldung.
Weitere Werkzeuge listet die Web Accessibility Initiative des W3C in ihrer Werkzeugliste, ohne Empfehlung einzelner Produkte. Dort steht auch der Satz, der für alle gilt: „Tools cannot check all accessibility aspects automatically. Human judgement is required.“ Ein Werkzeug erkennt, dass ein Bild einen Alternativtext hat, aber nicht, ob der Text das Bild beschreibt. Die Bundesfachstelle Barrierefreiheit nennt Schnelltests im Netz ausdrücklich keine vollständigen Tests; sie gäben nur einen groben Eindruck.
Lassen Sie den automatischen Lauf auf mindestens fünf Seiten laufen: Startseite, eine Inhaltsseite, eine Seite mit Formular, eine Liste wie Blog oder Produkte und eine Seite mit eingebetteten Inhalten wie Karte oder Video. Fehler in Kopf und Fuß tauchen dann auf allen fünf auf und lassen sich einmal beheben.
Schritt 2 · Tastatur
Tastatur-Test in zehn Minuten
Legen Sie die Maus zur Seite und öffnen Sie die Startseite. Tab springt zum nächsten Bedienelement, Umschalt und Tab zurück, Enter löst Links und Knöpfe aus, die Leertaste ebenfalls Knöpfe und Kontrollkästchen, Escape schließt Menüs und Dialoge. In Safari auf dem Mac springt Tab Links erst an, wenn in den Einstellungen unter „Erweitert“ die Option „Über Tabulator jedes Objekt auf einer Webseite hervorheben“ aktiv ist; für den Test eignen sich Chrome, Edge oder Firefox ohne Umstellung.
Sprunglink (1 Minute): Der erste Tab-Druck zeigt einen Link wie „Zum Inhalt“, der das Menü überspringt (WCAG 2.4.1).
Fokus sichtbar (2 Minuten): Bei jedem Tab-Druck ist erkennbar, wo der Fokus steht (2.4.7), und kein fester Kopfbereich oder Cookie-Hinweis verdeckt das fokussierte Element ganz (2.4.11).
Reihenfolge (1 Minute): Der Fokus wandert in der Lesereihenfolge, nicht kreuz und quer über die Seite (2.4.3).
Navigation (2 Minuten): Untermenüs öffnen sich mit Enter oder Leertaste, lassen sich mit Tab durchlaufen und mit Escape schließen; alle Funktionen sind ohne Maus erreichbar (2.1.1).
Formular (2 Minuten): Jedes Feld ist erreichbar, Auswahllisten und Kontrollkästchen bedienbar; schicken Sie das Formular leer ab, und die Fehlermeldung nennt das Feld und den Fehler in Text (3.3.1).
Dialoge und Einbettungen (1 Minute): Aus Cookie-Banner, Video oder Karte kommt der Fokus mit der Tastatur wieder heraus (2.1.2).
Notieren (1 Minute): Jeder Befund mit Seite, Element und Kriterium ins Protokoll unten.
Das sind 1 + 2 + 1 + 2 + 2 + 1 + 1 = 10 Minuten für eine Seite. Wiederholen Sie den Test für jede Vorlage, nicht für jede Seite: Zwanzig Leistungsseiten mit gleichem Aufbau brauchen einen Durchgang.
Schritt 3 · Sehen
Kontraste und Textgrößen
Für Text verlangt WCAG 2.2 in Kriterium 1.4.3 ein Kontrastverhältnis von mindestens 4,5:1, für großen Text ab 18 Punkt oder 14 Punkt fett 3:1. Bedienelemente, Rahmen von Eingabefeldern und der Fokusrahmen brauchen nach 1.4.11 mindestens 3:1 zur Umgebung. In den Chrome-Entwicklertools zeigt der Prüfmodus beim Überfahren eines Textes das Kontrastverhältnis an; der Bereich „CSS Overview“ listet alle Kontrastprobleme einer Seite auf einmal.
Typische Stellen, die automatische Werkzeuge nicht sicher bewerten: Text auf Fotos und Verläufen, Platzhaltertext in hellgrau, Zustände wie Hover oder deaktiviert.
Danach der Zoom. Stellen Sie den Browser auf 200 Prozent: Texte müssen ohne Verlust von Inhalt oder Funktion lesbar bleiben (1.4.4). Dann auf 400 Prozent bei einem 1.280 Pixel breiten Fenster: Das entspricht nach dem Hinweis in Kriterium 1.4.10 einer Breite von 320 CSS-Pixeln, und der Inhalt muss ohne waagerechtes Scrollen lesbar sein. Abgeschnittene Menüs und überlappende Texte fallen bei dieser Stufe sofort auf.
Schritt 4 · Hören
Prüfen mit dem Screenreader
Ein Screenreader liest die Seite so vor, wie der Code sie beschreibt. Die Bundesfachstelle Barrierefreiheit empfiehlt dafür den kostenlosen Screenreader NVDA für Windows; auf dem Mac ist VoiceOver eingebaut.
NVDA: Die NVDA-Taste ist Einfg (alternativ die Feststelltaste). Strg bricht die Sprachausgabe ab, NVDA und Pfeil nach unten liest ab der aktuellen Stelle vor. Im Lesemodus springen H zur nächsten Überschrift, 1 bis 6 zu einer Überschriftenebene, K zum nächsten Link, F zum nächsten Formularfeld und D zum nächsten Orientierungspunkt. NVDA und F7 öffnet eine Liste aller Links und Überschriften.
VoiceOver: Command und F5 schaltet VoiceOver ein und aus. Die VO-Taste ist Control und Option zusammen oder die Feststelltaste; VO und U öffnet den Rotor mit Listen etwa der Links und Überschriften.
Prüfen Sie mit der Liste der Überschriften, ob die Gliederung der Seite ohne Bild verständlich ist, mit der Liste der Links, ob jeder Linktext ohne Umgebung sagt, wohin er führt, und mit dem Formular, ob jedes Feld seine Beschriftung vorliest (3.3.2) und jeder Knopf einen Namen hat (4.1.2). Ein „Weiter“ ohne Ziel oder ein Knopf, der nur als „Schaltfläche“ angesagt wird, ist ein Befund. Bilder mit Inhalt brauchen einen Alternativtext, der den Inhalt wiedergibt; schmückende Bilder einen leeren, damit der Screenreader sie überspringt (1.1.1).
Schritt 5 · Protokoll
Ergebnisse dokumentieren
Ein Befund ohne Ort und Kriterium wird nicht behoben, weil niemand ihn wiederfindet. Schreiben Sie jeden Befund mit Seite, Element, Kriterium, Schwere und Zuständigkeit auf, und halten Sie fest, mit welchem Browser und welchem Hilfsmittel getestet wurde. Ein Protokoll mit Datum dient auch als Grundlage für die nächste Runde, weil sich Befunde abhaken und neue vergleichen lassen.
Wer einen vollständigen Test braucht, etwa vor einer Erklärung zur Barrierefreiheit, greift zu einem festgelegten Prüfverfahren. Der BIK BITV-Test prüft Websites in festen Prüfschritten nach BITV 2.0 und EN 301 549 und bietet daneben eine Selbstbewertung. Die harmonisierte Norm EN 301 549 in der Fassung V3.2.1 verweist für Webinhalte auf WCAG 2.1; nach Angabe der Bundesfachstelle wird sie im Rahmen des European Accessibility Act überarbeitet und soll in der Neufassung auf WCAG 2.2 verweisen. WCAG 2.2 ergänzt gegenüber 2.1 sechs Kriterien der Stufen A und AA und streicht das Kriterium 4.1.1. Wer nach WCAG 2.2 AA testet, deckt damit die bisherigen Anforderungen bis auf dieses gestrichene Kriterium ab.
Beim Bau neuer Websites gehört diese Prüfung bei uns zum Ablauf: Barrierefrei bauen ist Teil unserer Definition of Done, und jeder Stand durchläuft vor der Auslieferung einen Lighthouse-Audit für Performance und Accessibility, wie unter Standards beschrieben. Eine offizielle Konformitätsbestätigung durch Dritte ersetzt das nicht, und wir behaupten auch keine.
Vorlage zum Kopieren; je Vorlage der Website eine Kopie, Kriterien nach WCAG 2.2.
PRÜFPROTOKOLL BARRIEREFREIHEIT
Website: https://www.example.com
Datum: TT.MM.JJJJ
Geprüft von:
Browser und Version:
Hilfsmittel: nur Tastatur / NVDA / VoiceOver / Zoom 200 % und 400 %
Seiten (eine je Vorlage):
1. Startseite: /
2. Inhaltsseite:
3. Seite mit Formular:
4. Listenseite:
5. Seite mit eingebetteten Inhalten:
AUTOMATISCHE PRÜFUNG
Werkzeug | Seite | Fehler | Bemerkung
axe | | |
Lighthouse (Wert Barrierefreiheit) | | |
WAVE | | |
HANDPRÜFUNG
Nr. | Prüfung | WCAG | erfüllt ja/nein | Seite | Element | Schwere | zuständig
1 | Sprunglink beim ersten Tab | 2.4.1 | | | | |
2 | Fokus sichtbar und nicht verdeckt | 2.4.7, 2.4.11 | | | | |
3 | Fokus-Reihenfolge folgt der Lesereihenfolge | 2.4.3 | | | | |
4 | Menüs und Bedienelemente ohne Maus nutzbar | 2.1.1 | | | | |
5 | Fehler im Formular als Text benannt | 3.3.1 | | | | |
6 | Keine Tastaturfalle in Dialogen und Einbettungen | 2.1.2 | | | | |
7 | Textkontrast mindestens 4,5:1 (großer Text 3:1) | 1.4.3 | | | | |
8 | Kontrast von Bedienelementen und Fokus 3:1 | 1.4.11 | | | | |
9 | Zoom 200 % ohne Verlust von Inhalt | 1.4.4 | | | | |
10 | 400 % bei 1280 px ohne waagerechtes Scrollen | 1.4.10 | | | | |
11 | Überschriften bilden die Gliederung ab | 1.3.1, 2.4.6 | | | | |
12 | Linktexte verständlich ohne Umgebung | 2.4.4 | | | | |
13 | Felder nennen ihre Beschriftung | 3.3.2 | | | | |
14 | Schaltflächen haben einen Namen | 4.1.2 | | | | |
15 | Bilder: Alternativtext oder leeres alt | 1.1.1 | | | | |
Schwere: blockierend (Aufgabe unmöglich), hoch (Aufgabe schwer), gering (umständlich).
NÄCHSTE PRÜFUNG
Datum:
Umfang:
Das Protokoll hat mehr Zeilen mit „nein“ als erwartet?
Auf unserer Seite zu Standards steht, nach welchen Regeln wir Barrierefreiheit, Sicherheit und Code-Qualität umsetzen und was wir bewusst nicht behaupten. Wenn eine neue Website ansteht, beschreibt die Seite zur Webseiten-Entwicklung, wie wir sie bauen.
Zum Selbsttest
Häufige Fragen
-
Nein. Werkzeuge wie axe, Lighthouse oder WAVE finden fehlende Beschriftungen, zu schwache Kontraste und Strukturfehler, aber sie können nicht beurteilen, ob ein Alternativtext passt, ob die Reihenfolge Sinn ergibt oder ob ein Ablauf ohne Maus funktioniert. Die Web Accessibility Initiative des W3C hält fest, dass dafür menschliches Urteil nötig ist. Ein voller Lighthouse-Wert zeigt deshalb nur, dass die automatischen Prüfungen bestanden sind.
-
Den automatischen Lauf bei jeder größeren Änderung an Vorlagen oder Komponenten, am besten fest im Ablauf vor der Veröffentlichung. Die Handprüfung mit Tastatur und Screenreader jedes Mal, wenn eine neue Vorlage, ein neues Formular oder ein neuer Baustein dazukommt, und sonst in einem festen Rhythmus, etwa einmal im Jahr für alle Vorlagen. Neue Inhalte von Redakteuren, etwa Bilder ohne Alternativtext, prüft ein Blick in die Redaktionsabläufe besser als ein Test der Technik.
Artikel teilen