Die Barrierefreiheit einer Website testest du kostenlos in vier Schritten: erst ein automatischer Test mit einer Browser-Erweiterung wie WAVE oder axe DevTools oder mit Lighthouse in Chrome, dann ein Tastaturtest ohne Maus, dann ein kurzer Durchgang mit einem Screenreader (NVDA unter Windows, VoiceOver auf dem Mac) und zuletzt eine Kontrastprüfung mit Pipette. Der Maßstab sind die Web Content Accessibility Guidelines (WCAG), Stufe AA. Kein Werkzeug nimmt dir das Urteil ab: Der Hersteller von axe schreibt selbst, dass sein Prüfkern im Schnitt 57 Prozent der WCAG-Probleme automatisch findet. Den Rest siehst du nur, wenn du die Seite selbst bedienst.
Ich habe meine eigene Website am 04.11.2026 geprüft, acht Seiten: automatisch mit axe, dazu von Hand Tastatur, Kontraste und Video. Einen Screenreader-Durchgang gab es dabei noch nicht. Das Ergebnis steht weiter unten mit allen Zahlen. Kurz vorweg: 207 Fundstellen, fast alle aus einer Handvoll Bauteile, die auf jeder Seite wiederkehren. Gebaut und technisch betreut wird kevinwelter.com von Ralf, meinem KI-Mitarbeiter für Websites; wie er arbeitet, steht auf Website mit KI erstellen und modernisieren. Ob deine Seite überhaupt barrierefrei sein muss, ist eine eigene Frage, die steht in Webdesign für Selbstständige: lohnt es sich?.
Die kostenlosen Werkzeuge im Überblick
WAVE läuft laut WebAIM vollständig im Browser, es geht keine Information an den WAVE-Server. Lighthouse rechnet einen gewichteten Durchschnitt aus Prüfungen, die bestanden oder nicht bestanden sind, gewichtet nach den Schweregraden von axe; Prüfungen, die ein Mensch beurteilen muss, zählen laut Google nicht. Eine 100 heißt also: Die automatischen Prüfungen sind bestanden, nicht mehr.
So testest du die Barrierefreiheit deiner Website
Schritt 1: automatischer Test
Öffne die wichtigsten Seitentypen, nicht nur die Startseite: einen Beitrag, eine Leistungsseite, das Kontaktformular, den Bestellweg. Lass auf jeder Seite WAVE oder axe laufen. Lies die Ergebnisse in zwei Stapeln. Der erste sind echte Verstöße, der zweite sind Stellen, die das Werkzeug nicht sicher beurteilen kann (bei axe „incomplete“). Den zweiten Stapel prüfst du von Hand, er enthält oft die wichtigeren Funde. Und sortier nach Ursache, nicht nach Seite: Kehrt ein Fehler auf jeder Seite wieder, sitzt er in einem gemeinsamen Bauteil wie Kopf, Fußzeile oder Hinweisleiste und wird einmal behoben.
Schritt 2: Tastaturtest
Leg die Maus weg. Mit Tab springst du vorwärts, mit Umschalt + Tab zurück, Enter öffnet Links, die Leertaste drückt Knöpfe, Esc schließt Menüs und Dialoge. Du achtest auf drei Dinge: Siehst du jederzeit, wo du bist (WCAG 2.4.7 verlangt einen sichtbaren Fokus)? Erreichst du alles, auch Menüs, Filter und Formular? Und kommst du schnell zum Inhalt? Ein Link „Zum Inhalt springen“ ganz oben ist der übliche Weg. Ihn verlangt WCAG nicht zwingend, die W3C-Techniken lassen auch saubere Bereiche (Landmarks) und Überschriften gelten, für Tastaturnutzer ist er trotzdem der bequemste.
Schritt 3: Screenreader
Zehn Minuten reichen für den ersten Eindruck. Auf dem Mac schaltest du VoiceOver laut Apple mit Befehl + F5 ein und aus. Unter Windows installierst du NVDA. Lass dir die Liste der Überschriften und die Liste der Links anzeigen: Ergeben sie ohne den Rest der Seite einen Sinn? Heißen Knöpfe, was sie tun? Werden Bilder mit einem Alternativtext angesagt, und schweigen dekorative Bilder?
Schritt 4: Kontraste
Normale Schrift braucht nach WCAG 1.4.3 ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, große Schrift (ab 18 Punkt oder 14 Punkt fett) 3:1. Mit der Pipette des Colour Contrast Analyser nimmst du beide Farben direkt vom Bildschirm ab. Achte besonders auf graue oder halb durchsichtige Schrift und auf Text über Bildern und Verläufen, die automatische Werkzeuge oft nicht berechnen können. Hat deine Seite einen Dunkelmodus, prüfst du beide Modi.
Meine eigene Website im Test
Ich habe kevinwelter.com am 04.11.2026 geprüft. Den Lauf gefahren hat Sebastian, der auf meiner Website die Beiträge schreibt und misst: axe-core 4.14.0 in einem Chromium-Browser über Playwright, nur lesend, Bildschirmbreite 1.280 Pixel, heller Modus. Geprüft wurden acht Seiten: Startseite, Blog-Übersicht, ein Blogbeitrag, Ralfs Team-Seite, Community, Kontakt, die englische Startseite und die KI-Grundlagen.
Das Ergebnis: Auf jeder der acht Seiten verletzen genau drei Regeln, zusammen sind es 207 Fundstellen. 184 davon, also fast neun von zehn, stammen aus drei Bauteilen, die auf jeder Seite stehen.
Von Hand nachgesehen: Die Fehler sind echt. Die Seite ist hell, die Schrift dunkel mit 50 bis 60 Prozent Deckkraft, das ergibt das helle Grau, das axe misst. Im Dunkelmodus, gleiche Startseite, bleiben nur 3 Kontrastfunde übrig, die drei „Ergebnis:“-Kästen mit 4,18:1. Auf dem Handy (390 Pixel breit) kommen auf der Startseite dieselben 22 Kontrast- und 4 Namensfunde.
Gut war: Alle 118 Bilder auf den acht Seiten haben ein alt-Attribut, jede Seite hat genau eine H1 und die richtige Sprache, und der Tastaturfokus ist als 2 Pixel breiter Rahmen sichtbar. Nicht geprüft habe ich Screenreader, Zoom und Formulare. Weniger gut: Es gibt keinen Link „Zum Inhalt springen“, vor dem Hauptinhalt der Startseite liegen 13 Tab-Stopps. Und der wichtigste Fund kam nicht aus der Zählung, sondern aus dem Stapel „von Hand prüfen“: Das Einblick-Video auf meiner Community-Seite, in dem ich selbst erzähle, dauert gut drei Minuten und hat keine Untertitelspur. In zwei Standbildern, die Sebastian aus dem Video gezogen hat, sind auch keine eingebrannten Untertitel zu sehen. Für aufgezeichnete Videos mit Ton verlangt WCAG 1.2.2 Untertitel, schon auf der untersten Stufe A. Wie das ohne viel Aufwand geht, steht in Untertitel automatisch erstellen: Anleitung.
Stand 04.11.2026 ist davon noch nichts behoben. Die vollständige Liste mit Fundort und Vorschlag ist geschrieben; umgesetzt wird sie nach Ralfs festem Ablauf: bauen, Desktop und Mobil prüfen, live erst nach meiner Freigabe. Wie so eine Prüfung in die regelmäßige Pflege passt, steht in Website-Wartung: Aufgaben, Checkliste, Kosten.
Was das Gesetz verlangt, kurz
Das ist keine Rechtsberatung, sondern die Einordnung vor dem Test. Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für Online-Angebote, über die Verbraucher einen Vertrag schließen; Kleinstunternehmen mit Dienstleistungen sind ausgenommen (§ 3 Abs. 3 BFSG), wer genau betroffen ist, steht in Webdesign für Selbstständige.
Laut der Bundesfachstelle Barrierefreiheit ist die Norm EN 301 549 derzeit die zentrale technische Referenz; sie verweist auf Erfolgskriterien der WCAG 2.1, eine aktualisierte Fassung soll auf WCAG 2.2 verweisen. Ein Test nach WCAG 2.2, Stufe AA, wie oben deckt beides ab. Zuständig für Beschwerden ist die Marktüberwachungsstelle der Länder. Die Gesetzesstellen im Einzelnen stehen in KI-Website-Generatoren im Vergleich. Im Zweifel klärst du deinen Fall mit einer Anwältin.
Wo Ralf ins Spiel kommt
Ralf hat über 20 Kunden-Websites gebaut und betreut kevinwelter.com technisch. Zu seinem Ablauf gehören Build, Screenshots, Mobilansicht und Klickwege, und was live geht, entscheidet ein Mensch. Ein Barrierefreiheits-Test passt in genau diese Prüfstufe: Ein Lauf mit axe vor jedem Livegang zeigt neue Kontrast- und Namensfehler, bevor sie über ein gemeinsames Bauteil auf allen Seiten stehen. Bei einem Neubau oder einer Modernisierung mit KI ist das am billigsten, denn Farben, Schriftgrößen und Bedienung werden im Entwurf festgelegt.
Häufige Fragen
Welches kostenlose Werkzeug ist das beste?
Für den Einstieg WAVE, weil es die Funde direkt in der Seite zeigt. Für Entwickler axe DevTools, weil es den Fundort als Selektor liefert. Lighthouse ist schon in Chrome eingebaut. Alle drei ersetzen weder den Tastatur- noch den Screenreader-Test.
Reicht ein Lighthouse-Wert von 100?
Nein. Der Wert misst nur die automatischen Prüfungen; Prüfungen, die ein Mensch beurteilen muss, zählen laut Google nicht hinein. Ein fehlender Untertitel wie in meinem Video senkt den Wert nicht.
Was ist ein Barrierefreiheits-Checker?
Ein Werkzeug, das den Code einer Seite gegen Regeln prüft, meist die WCAG. Kostenlose Checker sind WAVE, axe DevTools und Lighthouse. Das W3C sagt dazu klar: Solche Werkzeuge können Barrierefreiheit nicht feststellen, sie helfen nur dabei.
Welche Fehler sollte ich zuerst suchen?
Bei mir waren es zu blasse Schrift, ein vorgelesener Name, der nicht zum sichtbaren Text passt, und ein Video ohne Untertitel. Prüf außerdem gezielt Alternativtexte für Bilder, Beschriftungen von Formularfeldern und ob alles mit der Tastatur bedienbar ist; das verlangt WCAG schon auf Stufe A (1.1.1, 3.3.2, 2.1.1).
Muss ich nach WCAG 2.1 oder 2.2 prüfen?
Prüf nach WCAG 2.2, Stufe AA. Sie ist seit Oktober 2023 W3C-Empfehlung (aktuelle Fassung vom 12. Dezember 2024), und wer 2.2 erfüllt, erfüllt auch die 2.1, auf die die EN 301 549 heute verweist.
Wie du weitermachst
Nimm dir eine Stunde und fünf Seiten deiner Website: Startseite, eine Leistungsseite, einen Beitrag, das Kontaktformular und, falls vorhanden, den Bestellweg. Lass auf jeder WAVE oder axe laufen, schreib die Funde nach Ursache auf, nicht nach Seite, und mach danach den Tastaturtest und zehn Minuten mit VoiceOver oder NVDA. Die Ursachen, die auf jeder Seite wiederkehren, behebst du zuerst. Wenn du das an einen KI-Mitarbeiter abgeben willst, der baut, prüft und erst nach deiner Freigabe live schaltet: Ralf gibt es als fertige, getestete Vorlage in der Stufe Premium meiner Community Claude Practitioners.
