Website auf Barrierefreiheit prüfen: Anleitung in 7 Schritten (2026)

Mit dem Barrierefreiheitsstärkungsgesetz seit 28. Juni 2025 ist die Frage nicht mehr "Sollten wir prüfen?", sondern "Wie prüfen wir am besten?". Diese Anleitung zeigt Ihnen sieben Schritte vom schnellen automatisierten Check bis zum manuellen Screenreader-Test. Sie funktioniert für jede Website und braucht keine bezahlten Tools.

Was Sie prüfen sollten und warum

Eine vollständige Barrierefreiheits-Prüfung deckt drei Ebenen ab:

1. Automatisierte Checks: Schnell, decken etwa 30 bis 40 Prozent der WCAG-Kriterien ab
2. Manuelle Code-Inspektion: Browser-DevTools, Quelltext, ARIA-Validität
3. Reale Nutzungstests: Mit Screenreader, Tastatur, Zoom

Nur die Kombination liefert eine belastbare Aussage. Wer sich auf eine einzelne Methode verlässt, übersieht die Hälfte der Probleme.

Schritt 1: Schneller Online-Check mit unserem Tool

Der schnellste Einstieg ist unser Barrierefreiheits-Check-Tool. URL eingeben, Sekunden warten, Bericht lesen. Das Tool prüft gegen über 20 WCAG-2.2-Kriterien: Alt-Texte, Heading-Hierarchie, Form-Labels, Skip-Link, Landmarks, Sprache, Viewport, tabindex und mehr.

Vorteil gegenüber lokal installierten Tools: Sie müssen nichts einrichten und bekommen einen lesbaren Bericht mit Lösungsvorschlägen pro Befund. Das Ergebnis ist Ihr Startpunkt, nicht das Ende des Audits.

Schritt 2: Lighthouse-Test im Chrome-Browser

Chrome bringt mit Lighthouse einen integrierten Accessibility-Audit. So nutzen Sie ihn:

1. Seite öffnen, die geprüft werden soll
2. DevTools öffnen (F12 oder Rechtsklick, Untersuchen)
3. Tab "Lighthouse" auswählen
4. Mode "Navigation", Category "Accessibility" aktivieren
5. "Analyze page load" klicken

Lighthouse nutzt intern axe-core, eine etablierte Test-Engine. Sie bekommen einen Score von 0 bis 100 und eine Liste der Probleme. Wichtig: Ein 100er-Score bedeutet nicht, dass die Seite barrierefrei ist. Er bedeutet nur, dass die automatisch prüfbaren Kriterien erfüllt sind.

Schritt 3: axe DevTools Browser-Extension installieren

Die axe DevTools sind die wichtigste Browser-Extension für Accessibility-Tests. Kostenlos für Chrome, Firefox und Edge.

• Hersteller: Deque Systems
• Installation: Chrome Web Store oder Firefox Add-ons
• Bedienung: F12, Tab "axe DevTools", "Scan All of My Page"

Vorteil gegenüber Lighthouse: Strukturierter, mit Severity-Markierung, mit direkten Links zu WCAG-Kriterien und Lösungsbeispielen. Die kostenlose Version reicht für die meisten Fälle.

Schritt 4: Tastatur-Test ohne Maus

Setzen Sie die Maus zur Seite. Versuchen Sie, jede wichtige Aktion auf Ihrer Website nur mit der Tastatur auszuführen. Drei zentrale Tests:

Tab-Navigation

Tab-Taste drücken. Wandert der Fokus durch die Seite? Sehen Sie immer, wo Sie gerade sind?

• Problem 1: Fokus nicht sichtbar. Ursache meist outline: none in CSS ohne Ersatz.
• Problem 2: Tab überspringt Bereiche. Ursache: tabindex="-1" an falscher Stelle oder display: none-Elemente, die fokussierbar sein sollten.
• Problem 3: Tab-Reihenfolge unlogisch. Ursache: Positive tabindex-Werte (verboten in WCAG) oder Layout per CSS verschoben.

Aktion mit Enter und Space

Fokus auf einen Button setzen, Enter drücken. Die Aktion muss ausgelöst werden. Bei Custom-Widgets fehlt das oft, weil ein <div onclick> keine Tastatur-Events fängt. Lösung: Echte <button>-Elemente nutzen oder Keydown-Handler ergänzen.

Modale Dialoge schließen

Modal öffnen, Escape drücken. Schließt sich das Modal? Wandert der Fokus zurück zum Auslöser? Wenn nicht, ist das Modal nicht WCAG-konform.

Schritt 5: Screenreader-Test

Der unverzichtbare Schritt. Ohne Screenreader-Test kann niemand seriös sagen, dass eine Website barrierefrei ist. So starten Sie:

Windows: NVDA installieren

NVDA von nvaccess.org herunterladen, installieren, mit Strg + Alt + N starten. Wichtigste Befehle:

• NVDA + Pfeil unten: Nächstes Element vorlesen
• H: Nächste Überschrift
• 1-6: Überschrift der Ebene 1 bis 6
• K: Nächster Link
• F: Nächstes Formularfeld
• D: Nächste Region (Landmark)
• NVDA + F7: Element-Liste öffnen
• NVDA + Q: Beenden

macOS: VoiceOver aktivieren

Cmd + F5 aktiviert VoiceOver. Bedienung mit der VO-Taste (Control + Option):

• VO + Pfeil rechts: Nächstes Element
• VO + H: Nächste Überschrift
• VO + U: Rotor (Auswahl von Elementtypen)

Was Sie testen sollten

1. Heading-Navigation: Erst alle H1-H6 durchgehen, danach selektiv tiefer. Ist die Struktur logisch?
2. Linktexte: K-Taste oder Linkliste öffnen. Sagen die Linktexte aus, wo es hingeht?
3. Formulare: F-Taste, jedes Feld muss klar benannt sein, Hilfetexte und Fehlermeldungen müssen vorgelesen werden.
4. Bilder: Mit Alt-Text vorgelesen oder übersprungen, wenn dekorativ?
5. Live-Updates: Suchergebnisse, Validierungen, neu eingefügte Inhalte werden angekündigt?

Schritt 6: Kontrast und Typografie prüfen

Drei kostenlose Tools für die visuelle Prüfung:

WCAG 2.2 verlangt mindestens 4,5:1 für Fließtext und 3:1 für großen Text (ab 18pt oder 14pt fett). Für UI-Elemente wie Buttons und Border-Lines genügen 3:1 (WCAG 1.4.11). Hellgraues Auf-Weiß ist fast immer zu wenig.

Zoom-Test: Mit Strg + + (Windows) oder Cmd + + (macOS) auf 200 Prozent zoomen. Bleibt das Layout lesbar? Kein horizontales Scrollen? Keine abgeschnittenen Texte?

Schritt 7: Mobile-Test

40 Prozent der Web-Zugriffe kommen vom Smartphone, und Accessibility-Probleme verschärfen sich oft auf kleinen Bildschirmen. Drei Tests:

1. Touch-Target-Größe: Mit Daumen Buttons treffen können (min. 44x44 CSS-Pixel, WCAG 2.2.8 fordert sogar nur 24x24, Apple HIG empfiehlt 44).
2. Zoom-Verhalten: Pinch-Zoom muss möglich sein. Im viewport-Meta NIE user-scalable=no setzen.
3. iOS VoiceOver / Android TalkBack: Mobil-Screenreader testen.

Was nach dem Check kommt

Wenn Sie alle sieben Schritte durchlaufen haben, kennen Sie den Status Ihrer Website. Drei Ergebnisse sind typisch:

Score 90+

Saubere Basis. Restaufgaben sind oft Details, die in einigen Stunden behoben werden können. Erklärung zur Barrierefreiheit verfassen (BFSG-Pflicht), Feedback-Mechanismus einrichten, fertig.

Score 60 bis 89

Solide, aber Lücken. Typischer Aufwand für die Konformität: 20 bis 60 Stunden, je nach Anzahl der Templates. Priorisieren Sie nach Schwere und Aufwand. Quick Wins zuerst: Alt-Texte ergänzen, Skip-Link einbauen, Heading-Hierarchie aufräumen.

Score unter 60

Grundlegender Handlungsbedarf. Hier empfiehlt sich ein vollständiger Accessibility Audit durch erfahrene Hände. Wir bei PAKU Media auditieren Websites in Bielefeld und ganz OWL nach WCAG 2.2 AA, mit manuellen Tests und priorisiertem Maßnahmenplan.

Drei häufige Fehler beim eigenen Check

1. Nur automatische Tools nutzen: Sie übersehen 60 bis 70 Prozent der Probleme.
2. Score über 90 als "fertig" interpretieren: Ein hoher Score ist Voraussetzung, kein Beweis.
3. Den Screenreader-Test überspringen: Ohne Screenreader-Test ist die Aussage zur Konformität nicht belastbar.

Weiter geht es

Sie haben Ihre Website geprüft. Was nun?

• Pillar-Seite: Barrierefreies Webdesign nach WCAG 2.2 AA
• Checkliste: WCAG 2.2 AA zum Abhaken
• BFSG für Websites: Pflicht, Ausnahmen, Strafen
• Tool: Kostenloser Barrierefreiheits-Check

Oder fragen Sie ein kostenloses Audit-Gespräch an. Wir analysieren Ihre Website manuell, mit Screenreader und Tastatur, und liefern einen konkreten Maßnahmenplan. Termin in Bielefeld buchen.