Was beim Test überhaupt geprüft wird: WCAG-Kriterien
Die Grundlage für Barrierefreiheitstests ist der WCAG-Standard (Web Content Accessibility Guidelines). Aktuell ist Version 2.1 maßgeblich, Version 2.2 ist seit 2023 veröffentlicht. Die Kriterien sind in vier Hauptprinzipien gegliedert:
Wahrnehmbar: Inhalte müssen für alle Nutzer erkennbar sein, auch ohne Sehen oder Hören.
- Alle Bilder brauchen einen beschreibenden Alternativtext
- Videos brauchen Untertitel oder Transkripte
- Inhalte dürfen nicht nur über Farbe unterschieden werden
- Farbkontraste müssen ausreichend stark sein (mindestens 4,5:1 für normalen Text)
Bedienbar: Die Website muss ohne Maus nutzbar sein.
- Alle Funktionen müssen per Tastatur erreichbar sein
- Der Fokus muss sichtbar sein (kein unsichtbarer Cursor)
- Nutzer brauchen genug Zeit, keine automatisch ablaufenden Inhalte ohne Stopp-Option
- Keine Inhalte, die Anfälle auslösen können (Blitzen über 3x/Sekunde)
Verständlich: Inhalte und Bedienung müssen nachvollziehbar sein.
- Sprache der Seite ist im Code hinterlegt
- Fehler in Formularen werden klar beschrieben
- Navigation ist konsistent aufgebaut
Robust: Die Website muss mit verschiedenen Technologien funktionieren.
- Valider, sauberer HTML-Code
- Screenreader-kompatible Formularfelder mit korrekten Labels
- Korrekte ARIA-Attribute wo nötig
Die Konformitätsstufen reichen von A (Mindestanforderung) über AA (Standard für Österreich und EU) bis AAA (höchste Stufe, für die meisten Websites nicht vollständig erreichbar).
Kostenlose Tools für den ersten Test
WAVE (Web Accessibility Evaluation Tool)
WAVE ist eines der bekanntesten und übersichtlichsten Tools für Accessibility-Tests. Es gibt es als Browser-Extension (Chrome und Firefox) sowie unter wave.webaim.org für direkte URL-Eingabe.
WAVE zeigt Fehler direkt auf der Website an, mit farbigen Icons, die den jeweiligen Fehler markieren. Ein rotes Icon steht für Fehler, ein gelbes für Warnungen, ein grünes für korrekte Implementierungen. Das macht es leicht, Probleme im Kontext der Seite zu sehen, statt durch eine abstrakte Liste zu scrollen.
Was WAVE gut erkennt: fehlende Alternativtexte, fehlende Formular-Labels, leere Links, fehlende Sprachauszeichnung, Kontrastprobleme. Was WAVE nicht erkennt: ob ein Alternativtext inhaltlich sinnvoll ist, ob Tastaturnavigation tatsächlich funktioniert, ob ein Screenreader die Seite verständlich vorliest.
axe DevTools
axe ist als Browser-Extension für Chrome und Firefox verfügbar. Es ist etwas technischer als WAVE, dafür sehr präzise: Die Ergebnisse sind nach Regeln sortiert und enthalten direkte Links zur Dokumentation. Besonders nützlich für Entwickler, weil axe auch in der Browser-Konsole und in automatisierten Tests eingesetzt werden kann.
axe unterscheidet zwischen Fehlern (violations), Best-Practice-Hinweisen und nicht automatisch prüfbaren Kriterien (incomplete). Dieser dritte Bereich ist wichtig: er zeigt, wo ein Mensch nachschauen muss, weil das Tool keine sichere Aussage treffen kann.
Lighthouse (Google)
Lighthouse ist in den Chrome DevTools eingebaut (F12, dann „Lighthouse“-Tab) und liefert neben Performance und SEO auch einen Accessibility-Score von 0 bis 100. Für einen schnellen Überblick ist es praktisch, weil keine Installation nötig ist.
Der Score sagt allerdings nichts darüber aus, ob eine Website wirklich WCAG-konform ist. Eine Seite kann 90 von 100 Punkten haben und trotzdem kritische Zugänglichkeitsprobleme haben, die Lighthouse nicht misst. Der Score ist ein Indikator, kein Zertifikat.
| Tool | Verfügbarkeit | Stärken | Beste Nutzung für |
|---|---|---|---|
| WAVE | Browser-Extension, Web | Visuell, leicht verständlich | Erste Überprüfung, Nicht-Entwickler |
| axe DevTools | Browser-Extension | Präzise, entwicklerfreundlich | Technische Analyse, Entwickler |
| Lighthouse | In Chrome eingebaut | Schnell, kein Setup nötig | Überblick neben Performance & SEO |
| Colour Contrast Analyser | Desktop-App (kostenlos) | Kontrastprüfung für beliebige Farben | Designphase, spezifische Farbprüfung |
| Screen Reader (NVDA, VoiceOver) | Kostenlos (NVDA für Windows) | Echte Nutzererfahrung | Manuelle Überprüfung |
Was automatische Tests nicht erkennen
Das ist der entscheidende Punkt, der bei vielen Barrierefreiheits-Diskussionen fehlt: Automatische Tools prüfen nur das, was sich regelbasiert prüfen lässt. Das sind etwa 30 bis 40 Prozent aller WCAG-Kriterien.
Was kein Tool verlässlich prüfen kann:
Qualität von Alternativtexten. Ein Tool erkennt, ob ein Bild einen Alt-Text hat. Ob dieser Alt-Text das Bild treffend beschreibt, kann kein Algorithmus beurteilen. „Bild“ oder „photo123.jpg“ sind formal vorhanden, inhaltlich aber wertlos für jemanden, der das Bild nicht sehen kann.
Tastaturnavigation in der Praxis. Ob alle interaktiven Elemente per Tab-Taste erreichbar und bedienbar sind, lässt sich nur durch manuelle Tests wirklich prüfen. Besonders bei JavaScript-lastigen Interfaces wie Dropdowns, Modals oder Sliders gibt es hier regelmäßig Probleme.
Logische Lesereihenfolge. Screenreader lesen Inhalte in der DOM-Reihenfolge, das kann deutlich von der visuellen Anordnung abweichen. Das ergibt sich erst beim tatsächlichen Durchhören der Seite mit einem Screenreader.
Verständlichkeit von Fehlermeldungen. Formularfehlermeldungen können vorhanden und technisch korrekt verlinkt sein, aber für Nutzer mit kognitiven Einschränkungen trotzdem unverständlich formuliert sein.
Kontextabhängige Barrierefreiheit. Ob Inhalte in einem bestimmten Kontext verständlich sind, hängt von Nutzererfahrung und Kontext ab. Das ist nicht automatisierbar.
Schritt für Schritt: So testet Ihr Eure Website
Schritt 1: Browser-Extension installieren. Entweder WAVE oder axe DevTools im Browser installieren. Beide sind kostenlos.
Schritt 2: Wichtigste Seiten auswählen. Nicht jede Unterseite muss einzeln geprüft werden. Startseite, Kontaktseite, wichtigste Leistungsseite und eine Unterseite mit Formular sind ein sinnvoller Start.
Schritt 3: Test ausführen und Fehler dokumentieren. Extension öffnen, Seite prüfen, Fehler mit Screenshot und Beschreibung festhalten. Bei WAVE auf „Details“ klicken für eine vollständige Liste.
Schritt 4: Manuelle Grundprüfung. Tab-Taste auf der Seite durchgehen: Ist jedes interaktive Element erreichbar? Ist der Fokus sichtbar? Alle Bilder auf sinnvolle Alternativtexte prüfen.
Schritt 5: Ergebnisse priorisieren. Nicht alle Fehler sind gleich schwer. Fehlende Alt-Texte auf Hauptbildern oder nicht bedienbare Formulare haben höhere Priorität als Warnungen zu optionalen ARIA-Attributen.
Wann ein professioneller Audit sinnvoll ist
Ein selbst durchgeführter Test ist ein guter Einstieg. Für bestimmte Situationen ist ein professioneller Accessibility-Audit aber deutlich sinnvoller:
Gesetzliche Verpflichtung. Öffentliche Stellen, Unternehmen mit Sitz in Österreich ab 250 Mitarbeitern und Unternehmen, die unter den European Accessibility Act (EAA) fallen, brauchen keinen selbst durchgeführten Test, sie brauchen nachweisbare WCAG-AA-Konformität.
Grundlegende Überarbeitung. Wenn eine Website in der Entwicklung so weit von Barrierefreiheitsanforderungen entfernt ist, dass einfaches Nachbessern nicht ausreicht, braucht es eine strukturierte Analyse vor der nächsten Entwicklungsphase.
Externe Kommunikation. Wer Barrierefreiheit aktiv kommunizieren oder eine Accessibility-Erklärung veröffentlichen will, braucht eine verlässliche Prüfung als Grundlage.
Ein professioneller Audit kombiniert automatische Tools mit manueller Prüfung und echten Screenreader-Tests. Das Ergebnis ist ein strukturierter Bericht mit priorisierten Maßnahmen, nicht nur eine Fehlerliste.
Was nach dem Test zu tun ist
Testergebnisse sind keine Dekoration. Der Wert liegt in der Behebung der gefundenen Probleme.
Sinnvoll ist eine Priorisierung nach zwei Faktoren: Schwere des Fehlers (blockiert der Fehler bestimmte Nutzergruppen komplett?) und Aufwand der Behebung (was ist in kurzer Zeit lösbar?). Fehlende Alt-Texte lassen sich oft in einer Stunde nachtragen. Grundlegende Probleme mit der Tastaturnavigation können dagegen Entwicklungsaufwand bedeuten.
Nach der Behebung: erneut testen. Besonders bei Entwicklungsänderungen ist es leicht, an einer Stelle etwas zu verbessern und an anderer Stelle unbeabsichtigt neue Probleme einzuführen.
FAQ zu Website barrierefrei testen
Welche Tools zum Testen sind kostenlos? WAVE, axe DevTools und Lighthouse sind alle kostenlos und für die meisten Prüfungen ausreichend. WAVE ist am einfachsten zu bedienen, axe ist am präzisesten für Entwickler. Lighthouse ist schon im Chrome-Browser eingebaut und braucht keine Installation. Für Kontrastprüfungen in der Designphase ist der Colour Contrast Analyser (kostenlose Desktop-App) empfehlenswert.
Bedeutet ein fehlerfreier automatischer Test, dass die Website barrierefrei ist? Nein. Automatische Tests erkennen ungefähr 30 bis 40 Prozent aller Accessibility-Probleme. Eine Seite kann alle automatisch prüfbaren Kriterien erfüllen und trotzdem für Screenreader-Nutzer kaum nutzbar sein. Fehlerfreie Tests sind ein gutes Zeichen, aber kein Beweis für WCAG-Konformität.
Wie lange dauert ein Website-Test? Ein erster automatischer Test einer einzelnen Seite dauert wenige Minuten. Eine realistische manuelle Grundprüfung der wichtigsten Seiten (Startseite, Kontakt, ein oder zwei Unterseiten) ist in ein bis zwei Stunden machbar. Ein vollständiger professioneller Audit einer mittelgroßen Website dauert je nach Umfang ein bis drei Tage.
Was mache ich mit den Testergebnissen? Fehler priorisieren nach Schwere und Aufwand. Mit den einfach behebbaren Problemen anfangen: fehlende Alt-Texte, fehlende Formular-Labels, unzureichende Kontraste. Diese lassen sich meist ohne großen Entwicklungsaufwand beheben. Für strukturelle Probleme wie fehlerhafte Tastaturnavigation ist in den meisten Fällen ein Entwickler nötig.
Ist Barrierefreiheitstesting in Österreich gesetzlich vorgeschrieben? Für öffentliche Stellen gilt das schon seit Jahren. Für private Unternehmen kommt mit dem European Accessibility Act (EAA), der in Österreich bis Juni 2025 umzusetzen ist, eine deutliche Ausweitung der Pflicht. Betroffen sind unter anderem Onlineshops und digitale Dienstleistungen ab einer bestimmten Unternehmensgröße. Regelmäßiges Testen ist für betroffene Unternehmen kein Goodwill mehr, sondern Teil der Compliance.
