“Können Sie mal checken, ob unsere Website barrierefrei ist?”
Klar. Dauert 5 Minuten mit einem automatischen Tool.
Nur: Das sagt dir fast nichts.
Automatische Accessibility-Tools finden etwa 30-40% der Probleme. Der Rest? Sitzt du mit Screenreader da, navigierst nur mit Tastatur, zoomst auf 400% und versuchst herauszufinden, warum das Formular nicht bedienbar ist.
Nach Jahren und dutzenden Audits habe ich einen Prozess entwickelt, der verlässliche Ergebnisse liefert. Nicht in 5 Minuten. Aber auch nicht in 3 Monaten.
Warum automatische Tools allein nicht funktionieren
WebAIM testet jedes Jahr eine Million Websites. Ergebnis 2024: Die häufigsten Probleme sind technisch einfach zu finden. Fehlende Alt-Texte, schlechte Kontraste, falsche Überschriften-Hierarchie.
Diese 30-40% kriegt axe-core, Lighthouse oder WAVE problemlos.
Aber dann:
Kann ein blinder Nutzer das Menü bedienen? Findet eine Tastatur-Navigation zurück aus dem Modal? Versteht ein Screenreader, was die Fehlermeldung bedeutet? Funktioniert der mehrstufige Checkout-Prozess?
Das sagt dir kein automatisches Tool.
Deswegen mein Ansatz: Automatisiert + Manuell + Spezialbereiche.
Phase 1: Automatisiertes Testing
Tool der Wahl: axe-core
Nicht weil es perfekt ist. Sondern weil es:
- Die meisten WCAG-Kriterien abdeckt
- Klare Erklärungen liefert
- Scriptbar ist (wichtig für größere Sites)
Mein Setup:
Python-Script mit Selenium, das die Website crawlt und auf jeder Seite axe-core ausführt. Raus kommen JSON-Reports mit:
- Welches WCAG-Kriterium verletzt wurde
- Severity (Critical, Serious, Moderate, Minor)
- Exakter HTML-Selektor
- Wie man’s fixt
Was das findet:
- Fehlende ARIA-Labels auf Buttons
- Kontrast-Probleme (Text vs. Hintergrund)
- Formular-Felder ohne Labels
- Kaputte Überschriften-Hierarchie
- Doppelte IDs
- Fehlende Landmarks
Was es NICHT findet:
- Ob die Tastatur-Navigation Sinn macht
- Ob der Screenreader die Seite versteht
- Ob Alt-Texte inhaltlich sinnvoll sind
- Ob komplexe Widgets bedienbar sind
Phase 2: Manuelles Testing
Hier wird’s mühsam. Aber hier findest du die echten Blocker.
Keyboard-Navigation
Maus weg. Nur Tastatur.
Tab, Shift+Tab, Enter, Space, Escape, Arrow-Keys. Mehr brauchst du nicht.
Was ich prüfe:
- Ist die Tab-Reihenfolge logisch?
- Sehe ich, wo der Fokus ist?
- Kann ich alle interaktiven Elemente erreichen?
- Komme ich aus Menüs/Modals wieder raus?
- Gibt es Keyboard-Traps?
Häufigste Probleme:
Custom-Dropdowns, die nur mit Maus funktionieren. Modals, die den Fokus nicht einfangen. Mega-Menüs ohne Escape-Möglichkeit.
Screenreader-Testing
NVDA + Firefox auf Windows. VoiceOver + Safari auf macOS/iOS.
Das ist der Reality-Check. Was hört ein blinder Nutzer wirklich?
Meine Screenreader-Checklist:
- Werden Landmarks angekündigt? (Banner, Navigation, Main, Contentinfo)
- Ist die Überschriften-Struktur logisch?
- Haben alle interaktiven Elemente aussagekräftige Namen?
- Sind Formular-Labels vorhanden und verständlich?
- Werden Fehler vorgelesen und mit Feldern verknüpft?
- Funktionieren komplexe Widgets (Tabs, Accordions)?
NVDA-Shortcuts, die ich ständig nutze:
H - Nächste Überschrift
1-6 - Überschrift Level 1-6
D - Landmark
K - Link
B - Button
F - Formularfeld
NVDA+F7 - Elementliste (Überschriften, Links, Landmarks)
Was dabei rauskommt:
“Button” ohne Namen. “Combobox, Combobox, Combobox” ohne zu wissen, welche. Fehlermeldungen, die irgendwo auf der Seite stehen, aber nicht vorgelesen werden.
Zoom & Text-Spacing
WCAG verlangt: Bis 200% Zoom muss alles nutzbar bleiben.
Chrome-DevTools aufmachen, auf 200% zoomen. Dann auf 400%.
Was ich suche:
- Horizontales Scrollen? (No-Go)
- Texte überlappen?
- Buttons abgeschnitten?
- Navigation noch bedienbar?
Text-Spacing-Test: Line-Height auf 1.5, Paragraph-Spacing verdoppeln. Bricht was?
Browser-Kompatibilität
Quick-Check in Chrome, Firefox, Safari, Edge. Desktop und Mobile.
Nicht jeder Browser rendered Focus-Styles gleich. Nicht jede CSS-Eigenschaft funktioniert überall.
Phase 3: Spezialbereiche
Formulare & Interaktive Prozesse
Kontaktformular? Newsletter-Signup? Mehrstufiger Checkout? Bewerbungsformular?
Hier musst du den kompletten Flow durchspielen:
Mit Tastatur:
- Alle Felder erreichbar?
- Validierung verständlich?
- Fehler werden angekündigt?
Mit Screenreader:
- Labels vorhanden?
- Pflichtfelder erkennbar?
- Fehlermeldungen mit Feldern verknüpft?
Absichtlich Fehler provozieren:
Feld leer lassen. Falsche E-Mail. Falsches Format. Wird der Nutzer geführt oder ratlos gelassen?
Die häufigsten Probleme (immer die gleichen)
Nach dutzenden Audits: Es wiederholt sich.
1. Buttons ohne aussagekräftige Labels
Hamburger-Menü ohne aria-label. Icon-Buttons ohne Text. Screenreader sagt: “Button, Button, Button.”
Hilfreich? Nein.
2. Formular-Felder ohne Labels
Placeholder-Text ist KEIN Label. Für Screenreader unsichtbar.
3. Farbkontraste unter WCAG-Minimum
Helles Grau auf Weiß. Gelb auf Weiß. “Sieht doch gut aus!” – mit perfekter Sicht auf einem High-End-Monitor.
WCAG verlangt 4.5:1 für normalen Text, 3:1 für großen Text.
4. Überschriften-Chaos
Fünf H1s. Oder gar keine H1. H1 → H3 → H2. Oder H1 → H4.
Für Screenreader-Nutzer: Navigationschaos.
5. Keyboard-Traps
Rein ins Modal, nicht mehr raus. Rein ins Mega-Menü, Escape funktioniert nicht.
6. Divs mit role=“button”
Warum nicht einfach <button>? Framework. Designer. Gewohnheit.
Das Ergebnis: Button, der sich nicht wie ein Button verhält.
Was im finalen Report steht
Kein 100-Seiten-PDF voller Buzzwords.
Executive Summary (1-2 Seiten)
Wo steht die Website? Wie viele Probleme? Wie kritisch? Was kostet die Lösung?
Für den Manager, der 5 Minuten Zeit hat.
Globale Probleme (thematisch gruppiert)
- Navigation & Menüstruktur
- Formulare & Eingaben
- Farbkontraste & Lesbarkeit
- Semantik & Struktur
- ARIA & Interaktive Komponenten
Jedes Problem mit:
- WCAG-Kriterium
- Severity
- Betroffene Seiten
- Code-Beispiel (Ist/Soll)
- Aufwandsschätzung
WCAG-Referenz
Welche Success Criteria verletzt? Level A, AA, AAA?
Die unbequemen Wahrheiten und was man immer wieder hört
“Wir haben Lighthouse getestet, alles grün!”
Lighthouse ist super für Performance. Für Accessibility? Scratching the surface.
“Unser Framework ist doch accessible!”
Frameworks geben dir Werkzeuge. Ob du sie richtig nutzt? Dein Problem.
“Das kostet doch Monate!”
Audit? 1-2 Wochen. Umsetzung bei halbwegs sauber gebautem Code? 2-4 Wochen für WCAG AA.
“Wir sind kein öffentlicher Dienst, betrifft uns nicht!”
EU-Richtlinien kommen. AGG-Klagen auch. Und ca. 15% deiner potenziellen Nutzer haben Einschränkungen.
“Können wir das nicht selbst machen?”
Klar. Aber: Hast du jemanden, der NVDA bedienen kann? Der WCAG 2.2 kennt? Der weiß, wo man suchen muss?
Wenn ja: Mach’s selbst.
Wenn nein: Hol dir Hilfe.
Wenn du ein Audit brauchst
Drei Fragen:
1. Wie wichtig ist WCAG-Konformität?
Gesetzliche Verpflichtung? Kundenanforderung? “Nice to have”?
2. Wie komplex ist deine Website?
Statische Seiten oder Web-App mit Custom-Components?
3. Was ist dein Zeitrahmen?
Stichtag in 2 Monaten oder “irgendwann mal”?
Basierend darauf: Quick-Audit in 2 Tagen oder Full-Audit in 2 Wochen.
Und dann: Machen. Nicht aufschieben.
Denn irgendwann merkt jemand, dass deine Website nicht zugänglich ist. Und dann wird’s teurer.
Der Realitätscheck
Ein gutes Audit gibt dir:
Klare Problemanalyse: Was ist kaputt? Wie kaputt?
Priorisierte Lösungen: Was sofort? Was später?
Realistische Aufwandsschätzungen: Nicht “6 Monate”. Sondern “3 Wochen für die kritischen Punkte”.
Umsetzbare Code-Beispiele: Entwickler können copy-pasten und verstehen.
Das ist der Unterschied zwischen “Haben wir gemacht” und “Funktioniert jetzt wirklich”.
Barrierefreiheit ist ein Prozess, kein Endzustand. Aber mit einem soliden Audit weißt du, wo du stehst und wo du hin musst.
Und das ist mehr als 90% der Websites haben.
Kommentare