Praxisleitfaden für Entwickler: Barrierefreiheit testen und umsetzen

Website auf Barrierefreiheit testen: Typische Probleme erkennen und beheben

Geschätzte Lesezeit: 12 Minuten

Kernaussagen

Automatisierte Tools + manuelle Tests: Ein audit barrierefreiheit braucht beides – automatisierte Checker (z. B. WAVE, axe, Lighthouse) und echte Nutzer-Tests.
Drei Hauptprobleme: Fehlende Alt-Texte, schlechte Farbkontraste und unzureichende Tastaturnavigation blockieren viele Nutzer.
Rechtlicher Hintergrund: Das BFSG macht Barrierefreiheit ab 2025 für viele Unternehmen verpflichtend; WCAG 2.1 Level AA ist das Mindestziel.
Workflow: Schnellscan → manuelle Basis-Tests → Screenreader-Test → Dokumentation & Priorisierung.

Inhaltsverzeichnis

Die wichtigsten Erkenntnisse vorab

Kurze Illustration der drei Hauptprobleme: Alt-Texte, Kontrast, Tastaturnavigation

Kurzfassung: Ein test barrierefreiheit website zeigt oft drei Kernprobleme: fehlende Alt-Texte, schlechte Farbkontraste und fehlerhafte Tastaturnavigation. Diese Barrieren betreffen Millionen Menschen.

Nutze automatisierte Tools wie WAVE oder axe für den Schnellcheck, aber ergänze sie immer durch manuelle Tests mit Tastatur und Screenreader. WCAG gibt den Rahmen vor; das BFSG verschärft die Pflichten ab 2025.

Warum Barrierefreiheit im Web mehr als nur ein Häkchen ist

Person mit Screenreader nutzt Vereinswebsite

Als ich die Website eines lokalen Laufvereins übernahm, fiel mir erst später auf, dass ein Mitglied mit Screenreader die Trainingszeiten nicht finden konnte. Barrierefreiheit ist kein Nice-to-have – sie ist essentiell für Menschen mit Behinderungen und oft auch sinnvoll für ältere Nutzer oder solche mit temporären Einschränkungen.

In Deutschland leben rund 10 Millionen Menschen mit einer anerkannten Behinderung. Viele nutzen assistive Technologien. Barrierefreiheit erhöht Reichweite, verbessert Usability und reduziert rechtliches Risiko (BFSG ab 2025). Die WCAG 2.1 bieten konkrete Kriterien, helfen aber nicht immer, die Praxis abzubilden – hier kommen Tests ins Spiel.

Die drei häufigsten Barrieren und wie sie Nutzer ausbremsen

Illustration: Drei Icons für Bilder, Farben, Tastatur

Die drei Probleme, die in fast jedem Test auftauchen, sind:

Fehlende oder falsche Alt-Texte
Schlechte Farbkontraste
Unvollständige Tastaturnavigation

Fehlende Alt-Texte – unsichtbare Bilder für Screenreader

Ohne das alt-Attribut bleiben Informationen verborgen. Alt-Texte sollten präzise sein: statt "Bild123.jpg" lieber "Läufer beim Zieleinlauf des Stadtmarathons". Dekorative Bilder erhalten alt="". Automatische Tools wie WAVE finden fehlende Alt-Texte schnell, können aber nicht beurteilen, ob ein Text sinnvoll ist – hierfür braucht es manuelle Kontrolle oder einen Screenreader-Test.

Kontrast-Schwächen – wenn Farben verschwimmen

WCAG fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text. Tools wie Chrome Lighthouse oder spezielle Contrast-Checker zeigen sofort problematische Kombinationen und schlagen passende Farbwerte vor. Gutes Kontrastdesign hilft nicht nur Menschen mit Sehbehinderung, sondern auch Nutzern bei Sonnenlicht oder bei ermüdeten Augen.

Tastaturnavigation – die vergessene Bedienart

Viele Nutzer navigieren ausschließlich per Tastatur. Test: Maus weglegen und die Seite komplett per Tab/Shift+Tab/Enter bedienen. Achte auf logische Tab-Reihenfolge, sichtbaren Fokus (niemals outline:none ohne Alternative) und erreichbare interaktive Elemente. ARIA kann helfen, aber falsches ARIA ist schlimmer als kein ARIA.

Automatisierte Tools – deine ersten Verbündeten beim Test

Screenshot-ähnliche Darstellung von WAVE, Lighthouse, axe

Automatisierte Tools liefern schnellen Überblick. Meine Favoriten:

WAVE: Sehr visuell, markiert Probleme direkt auf der Seite.
Google Lighthouse: In Chrome integriert, prüft Accessibility plus Performance und SEO.
axe DevTools: Detaillierte Hinweise zu WCAG-Kriterien.

Wichtig: Automatische Scanner finden nur etwa 30–50% der Probleme. Sie sind ein guter Startpunkt, aber kein Ersatz für manuelle Tests.

Manuelle Tests – wo die Maschinen versagen

Darstellung von Tastatur-, Screenreader- und Zoom-Tests

Tastatur-Test: 15 Minuten ohne Maus: Kannst du alle Menüs, Links und Formulare erreichen? Modal-Fallen sind typische Probleme.

Screenreader-Test: NVDA (Windows) oder VoiceOver (Mac/iOS) hören, wie die Seite vorgelesen wird: Sind Überschriften logisch? Werden Links sinnvoll angekündigt?

Zoom-Test: Browser auf 200% vergrößern: Bleibt alles lesbar und bedienbar?

Strukturprüfung: Saubere Überschriften-Hierarchie, semantische Elemente (<nav>, <main>, <article>) und korrekt gelabelte Formulare sind die Grundlage für Accessibility.

WCAG und BITV – die Spielregeln verstehen

Visualisierung von WCAG-Leveln A, AA, AAA

WCAG 2.1 (mit WCAG 2.2 als neuere Version) ist der internationale Standard. Konformitätsstufen: A, AA, AAA. Level AA ist das praktische Ziel für die meisten Websites. In Deutschland setzt die BITV 2.0 größtenteils WCAG 2.1 Level AA um; die EN 301 549 übersetzt Anforderungen für den europäischen Rechtskontext. Für ein professionelles audit barrierefreiheit nach BITV sind geschulte Prüfer nötig.

Typische Schwachstellen, die oft übersehen werden

Icons für Formulare, Überschriften, ARIA, Sprache

Formulare: Jedes Feld braucht ein <label>; Fehlermeldungen müssen textuell und programmatisch verknüpft sein. Farbe allein reicht nicht als Hinweis.

Überschriften-Hierarchie: Eine h1 pro Seite, dann logisch h2, h3 usw. Screenreader-Nutzer springen über Überschriften – chaotische Reihenfolgen zerstören die Orientierung.

ARIA: Nutze natives HTML, bevor du ARIA einsetzt. ARIA ist für komplexe Widgets gedacht; falsch eingesetzt kann es die Zugänglichkeit verschlechtern.

Sprachangabe: Das lang-Attribut im <html>-Tag ist wichtig: <html lang="de">. Ohne Sprache raten Screenreader oft falsch.

Dynamische Inhalte: Bei JavaScript-Änderungen helfen ARIA Live Regions (aria-live) – aber sparsam einsetzen, sonst wird's störend.

Der praktische Workflow: So testest du systematisch

Flowchart: Automatischer Scan → Manuelle Tests → Screenreader → Dokumentation

Ein strukturierter Ablauf spart Zeit:

Phase 1 – Automatischer Schnellcheck (15–30 Min): WAVE, Lighthouse, axe über Schlüssel-Seiten fahren.
Phase 2 – Manuelle Basis-Tests (30–45 Min): Tastatur, Zoom, Fokus-Indikatoren checken.
Phase 3 – Screenreader-Test (60+ Min): NVDA oder VoiceOver für echtes Nutzererlebnis.
Phase 4 – Dokumentation & Priorisierung (30 Min): Findings klassifizieren: kritisch, wichtig, nice-to-have.

Tools: WAVE, axe DevTools, Lighthouse, NVDA, VoiceOver, JAWS, WebAIM Contrast Checker, BIK Easy Checks, Aktion Mensch Schnelltest. Dokumentation mit Screenshots und konkreten Code-Stellen erleichtert die Umsetzung.

Kostenlos testen – Barrierefreiheits-Check starten

FAQ – Häufige Fragen zum Test auf Barrierefreiheit

Wie oft sollte ich meine Website auf Barrierefreiheit testen?

Bei größeren Änderungen am Design oder der Struktur solltest du immer einen Test durchführen. Ansonsten empfiehlt sich ein umfassender Check mindestens einmal im Jahr. Automatisierte Tests kannst du auch in deine CI/CD-Pipeline integrieren, damit bei jedem Release die Basics geprüft werden. Neue Features sollten von Anfang an barrierefrei entwickelt werden, nicht nachträglich gefixt.

Reichen automatisierte Tools für einen vollständigen Test?

Nein, definitiv nicht. Automatische Checker finden nur 30-50% der Probleme. Sie erkennen technische Fehler wie fehlende Alt-Attribute oder Kontrastverstöße, aber nicht, ob die Inhalte sinnvoll strukturiert sind oder die Nutzererfahrung stimmt. Manuelle Tests mit Tastatur und Screenreader sind unverzichtbar für ein realistisches Bild.

Welches Tool ist am besten für Einsteiger?

WAVE ist super für den Einstieg – visuell, intuitiv, direkt in der Seite markiert. Kombiniert mit dem Lighthouse-Test in Chrome hast du nen guten ersten Überblick. Für deutschsprachige Nutzer ist der Schnelltest von Aktion Mensch auch sehr zugänglich. Alle sind kostenlos und erfordern keine Installation.

Muss ich wirklich jede einzelne Seite testen?

Bei großen Websites ist das unrealistisch. Test repräsentative Seitentypen: Startseite, Navigationsseiten, Inhaltsseiten (z.B. Blogposts), Formulare, interaktive Elemente. Wenn deine Templates sauber sind, übertragen sich die Fixes meist auf alle Seiten dieses Typs. Bei kritischen Prozessen wie Checkout oder Registrierung solltest du aber gründlich sein.

Was kostet ein professionelles Barrierefreiheits-Audit?

Das variiert stark je nach Umfang. Ein BITV-Test für ne mittlere Website kann mehrere tausend Euro kosten, da geschulte Prüfer nach standardisiertem Verfahren arbeiten. Für kleinere Projekte gibt's auch günstigere Beratungsangebote. Viele Probleme kannst du aber mit den beschriebenen Methoden selbst identifizieren und beheben – das spart massiv Kosten.

Wie erkläre ich meinem Chef/Kunden, warum Barrierefreiheit wichtig ist?

Argumentiere wirtschaftlich: Mehr potenzielle Nutzer, besseres SEO (Google mag sauberes HTML und gute UX), weniger rechtliche Risiken (BFSG!), bessere Usability für alle. Barrierefreiheit ist kein Nischenthema – jeder wird mal älter, viele haben temporäre Einschränkungen (gebrochener Arm, Augeninfektion). Plus: Es ist einfach das Richtige.

Sind barrierefreie Websites immer hässlich?

Absolut nicht! Das ist ein Mythos. Barrierefreiheit bedeutet nicht, dass alles grau und langweilig sein muss. Du kannst kreativ designen und trotzdem gute Kontraste, klare Struktur und sauberes HTML haben. Viele moderne, schicke Websites sind hochgradig barrierefrei – Accessibility und gutes Design schließen sich nicht aus, sie ergänzen sich.

Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2?

WCAG 2.2 ist die neuere Version (veröffentlicht 2023) und fügt neun neue Erfolgskriterien hinzu, vor allem im Bereich Mobile und kognitive Barrierefreiheit. WCAG 2.1 ist aktuell noch der weit verbreitete Standard, auf den sich Gesetze wie BITV beziehen. Wenn du WCAG 2.1 Level AA erfüllst, bist du rechtlich auf der sicheren Seite – aber ein Blick auf 2.2 schadet nicht für zukunftssicheres Entwickeln.

Kann ich meine Website selbst barrierefrei machen oder brauche ich Experten?

Viele Verbesserungen kannst du selbst umsetzen, wenn du dich einarbeitest. Alt-Texte ergänzen, Kontraste anpassen, Fokus-Styles verbessern – das ist kein Hexenwerk. Für komplexere Anwendungen oder wenn rechtliche Konformität nachgewiesen werden muss, ist Expertenunterstützung sinnvoll. Aber starten kannst du definitiv selbst.

Wie teste ich PDFs auf Barrierefreiheit?

PDFs sind ein eigenes Thema. Sie müssen getaggt sein (strukturierte Metadaten), Lesereihenfolge muss stimmen, Alternativtexte für Bilder müssen vorhanden sein. Adobe Acrobat Pro hat einen Accessibility Checker integriert. PAC (PDF Accessibility Checker) ist ein kostenloses Tool. Generell gilt: PDFs aus Word oder InDesign exportieren und dabei die Barrierefreiheits-Optionen aktivieren. Gescannte PDFs ohne Texterkennung sind praktisch unzugänglich.

Praxisleitfaden für Entwickler: Barrierefreiheit testen und umsetzen